dbtk 0.8.0__tar.gz → 0.8.2__tar.gz

{dbtk-0.8.0 → dbtk-0.8.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dbtk
-Version: 0.8.0
+Version: 0.8.2
 Summary: Data Benders Toolkit - A lightweight toolkit for data integration, ELT and ETL
 Author: Scott Bailey <scottrbailey@gmail.com>
 License: MIT
@@ -39,7 +39,8 @@ Requires-Dist: lxml>=4.6.0; extra == "recommended"
 Requires-Dist: openpyxl>=3.0.0; extra == "recommended"
 Requires-Dist: phonenumbers>=8.12.0; extra == "recommended"
 Requires-Dist: python-dateutil>=2.8.0; extra == "recommended"
-Requires-Dist: usaddress>=0.5.11; extra == "recommended"
+Requires-Dist: usaddress==0.5.10; python_version < "3.7" and extra == "recommended"
+Requires-Dist: usaddress>=0.5.11; python_version >= "3.7" and extra == "recommended"
 Provides-Extra: postgresql
 Requires-Dist: psycopg2-binary>=2.9; extra == "postgresql"
 Requires-Dist: psycopg[binary]>=3.1; extra == "postgresql"
@@ -57,7 +58,8 @@ Requires-Dist: openpyxl>=3.0.0; extra == "all"
 Requires-Dist: xlrd>=1.2.0; extra == "all"
 Requires-Dist: phonenumbers>=8.12.0; extra == "all"
 Requires-Dist: python-dateutil>=2.8.0; extra == "all"
-Requires-Dist: usaddress>=0.5.11; extra == "all"
+Requires-Dist: usaddress==0.5.10; python_version < "3.7" and extra == "all"
+Requires-Dist: usaddress>=0.5.11; python_version >= "3.7" and extra == "all"
 Provides-Extra: dev
 Requires-Dist: pytest>=6.0; extra == "dev"
 Requires-Dist: pytest-cov>=2.10; extra == "dev"
@@ -70,7 +72,7 @@ Dynamic: license-file
 # DBTK - Data Benders Toolkit
 
 <div style="float: right; padding: 20px">
-    <img src="/docs/assets/databender.png" height="240" align="right" />
+    <img src="https://raw.githubusercontent.com/scottrbailey/dbtk/main/docs/assets/databender.png" height="240" align="right" />
 </div>
 
 **Control and Manipulate the Flow of Data** - A lightweight Python toolkit for data integration, transformation, and movement between systems.
@@ -80,9 +82,9 @@ Extract data from various sources, transform it through powerful operations, and
 This library is designed by and for data integrators.
 
 **DBTK aims to be fast and memory-efficient at every turn.** But it was designed to boost your productivity first and foremost.
-You have dozens (possibly hundreds) of interfaces, impossible deadlines, and multiple projects all happening at once. Your
-environment has three or more different relational databases. You just want to get stuff done instead of writing the same
-boilerplate code over and over or stressing over differences on a database server you don't use very often.  
+You have dozens, possibly hundreds, of interfaces, impossible deadlines, and multiple projects all happening at once. Your
+environment has different relational databases, each has its own quirks. You just want to get stuff done instead of writing the same
+boilerplate code over and over.  
 
 **Design philosophy:** Modern databases excel at aggregating and transforming data at scale. DBTK embraces
 this by focusing on what Python does well: flexible record-by-record transformations,
@@ -93,6 +95,47 @@ your database handle it. If you need dataframes and heavy analytics - reach for
 or polars. DBTK sits in between: getting your data where it needs to be, cleaned and
 validated along the way.
 
+## Why DBTK?
+
+Most ETL tools fall into one of two traps:
+
+- **Verbose boilerplate hell** — SQLAlchemy + pandas + custom loops, repeated across every
+  interface with minor variations, slowly accreting defensive code for every edge case
+- **Opaque black box** — so much is hidden that debugging feels like reverse-engineering
+  someone else's code
+
+DBTK threads the needle. It's declarative enough to eliminate repetition, but explicit enough
+that you stay in control. When something breaks, you know exactly where to look.
+
+The architecture is intentionally layered — use what you need, skip what you don't:
+
+```
+Record          → ergonomic row handling, memory-efficient at scale
+Table           → field mapping, transforms, validation, upserts
+DataSurge       → batched inserts with progress tracking and stats
+BulkSurge       → direct bulk loads (SQL*Loader, BCP, COPY) for maximum throughput
+readers/writers → consistent API across every file format and compression type
+```
+
+When developers convert existing jobs to DBTK, the result can be **half to a quarter the
+original code**. That reduction comes from specific things DBTK just handles:
+
+- **Key column validation** — DBTK throws a clear error if a key field is missing from the source.
+  No more writing null-guards before every upsert.
+- **Safe partial updates** — if a field is missing from the source, DBTK excludes it from the
+  UPDATE rather than overwriting with NULL. No more "did I just wipe a column?" paranoia.
+- **Batch loop elimination** — DataSurge handles chunking, committing, retries, and statistics.
+  No more hand-rolled batch loops.
+- **Zero-config logging** — one line sets up timestamped log files with auto-cleanup and a global
+  error flag. No logging boilerplate scattered through your pipeline.
+- **TableLookup shorthand** — define a lookup or validation in ~40 characters:
+  `'fn': 'validate:ranks:rank_code:preload'`. The `preload` hint pre-caches the table before
+  processing starts. What would otherwise be a custom class or 30-line function is a string.
+
+The code that remains is shorter, clearer, and still has all the functionality and checks. You
+finish the job and think *"that was satisfyingly elegant"* — not because corners were cut, but
+because the tool was collaborating with you instead of making you fight it.
+
 **Speed and Memory** The primary objective of DBTK is to give data integrators an elegant toolkit to speed up your development.
 But DBTK's throughput and memory usage are very good. BulkSurge streaming from a polars and doing direct loads to PostgreSQL will
 process 1M rows in 3-4 seconds. But even with a standard Python csv reader and numerous column transforms, DataSurge is able to

{dbtk-0.8.0 → dbtk-0.8.2}/README.md

@@ -1,7 +1,7 @@
 # DBTK - Data Benders Toolkit
 
 <div style="float: right; padding: 20px">
-    <img src="/docs/assets/databender.png" height="240" align="right" />
+    <img src="https://raw.githubusercontent.com/scottrbailey/dbtk/main/docs/assets/databender.png" height="240" align="right" />
 </div>
 
 **Control and Manipulate the Flow of Data** - A lightweight Python toolkit for data integration, transformation, and movement between systems.
@@ -11,9 +11,9 @@ Extract data from various sources, transform it through powerful operations, and
 This library is designed by and for data integrators.
 
 **DBTK aims to be fast and memory-efficient at every turn.** But it was designed to boost your productivity first and foremost.
-You have dozens (possibly hundreds) of interfaces, impossible deadlines, and multiple projects all happening at once. Your
-environment has three or more different relational databases. You just want to get stuff done instead of writing the same
-boilerplate code over and over or stressing over differences on a database server you don't use very often.  
+You have dozens, possibly hundreds, of interfaces, impossible deadlines, and multiple projects all happening at once. Your
+environment has different relational databases, each has its own quirks. You just want to get stuff done instead of writing the same
+boilerplate code over and over.  
 
 **Design philosophy:** Modern databases excel at aggregating and transforming data at scale. DBTK embraces
 this by focusing on what Python does well: flexible record-by-record transformations,
@@ -24,6 +24,47 @@ your database handle it. If you need dataframes and heavy analytics - reach for
 or polars. DBTK sits in between: getting your data where it needs to be, cleaned and
 validated along the way.
 
+## Why DBTK?
+
+Most ETL tools fall into one of two traps:
+
+- **Verbose boilerplate hell** — SQLAlchemy + pandas + custom loops, repeated across every
+  interface with minor variations, slowly accreting defensive code for every edge case
+- **Opaque black box** — so much is hidden that debugging feels like reverse-engineering
+  someone else's code
+
+DBTK threads the needle. It's declarative enough to eliminate repetition, but explicit enough
+that you stay in control. When something breaks, you know exactly where to look.
+
+The architecture is intentionally layered — use what you need, skip what you don't:
+
+```
+Record          → ergonomic row handling, memory-efficient at scale
+Table           → field mapping, transforms, validation, upserts
+DataSurge       → batched inserts with progress tracking and stats
+BulkSurge       → direct bulk loads (SQL*Loader, BCP, COPY) for maximum throughput
+readers/writers → consistent API across every file format and compression type
+```
+
+When developers convert existing jobs to DBTK, the result can be **half to a quarter the
+original code**. That reduction comes from specific things DBTK just handles:
+
+- **Key column validation** — DBTK throws a clear error if a key field is missing from the source.
+  No more writing null-guards before every upsert.
+- **Safe partial updates** — if a field is missing from the source, DBTK excludes it from the
+  UPDATE rather than overwriting with NULL. No more "did I just wipe a column?" paranoia.
+- **Batch loop elimination** — DataSurge handles chunking, committing, retries, and statistics.
+  No more hand-rolled batch loops.
+- **Zero-config logging** — one line sets up timestamped log files with auto-cleanup and a global
+  error flag. No logging boilerplate scattered through your pipeline.
+- **TableLookup shorthand** — define a lookup or validation in ~40 characters:
+  `'fn': 'validate:ranks:rank_code:preload'`. The `preload` hint pre-caches the table before
+  processing starts. What would otherwise be a custom class or 30-line function is a string.
+
+The code that remains is shorter, clearer, and still has all the functionality and checks. You
+finish the job and think *"that was satisfyingly elegant"* — not because corners were cut, but
+because the tool was collaborating with you instead of making you fight it.
+
 **Speed and Memory** The primary objective of DBTK is to give data integrators an elegant toolkit to speed up your development.
 But DBTK's throughput and memory usage are very good. BulkSurge streaming from a polars and doing direct loads to PostgreSQL will
 process 1M rows in 3-4 seconds. But even with a standard Python csv reader and numerous column transforms, DataSurge is able to

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/__init__.py

@@ -36,9 +36,9 @@ from .database import Database
 from .config import connect, set_config_file
 from .cursors import Cursor
 from .logging_utils import setup_logging, cleanup_old_logs, errors_logged
-from . import etl
 from . import readers
 from . import writers
+from . import etl
 
 # Simple, clean exports
 __all__ = [

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/cli.py

@@ -114,7 +114,8 @@ def checkup():
 
 def main():
     parser = argparse.ArgumentParser(prog='dbtk', description='DBTK command-line utilities')
-    subparsers = parser.add_subparsers(dest='command', required=True)
+    subparsers = parser.add_subparsers(dest='command')
+    subparsers.required = True  # required= kwarg not supported in Python 3.6
 
     # checkup
     subparsers.add_parser('checkup', help='Check for dependencies and configuration issues')

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/etl/base_surge.py

@@ -2,7 +2,7 @@
 import logging
 import time
 from abc import ABC, abstractmethod
-from typing import Iterable, Generator, Optional
+from typing import Iterable, Generator, Optional, Union
 import datetime as dt
 import tempfile
 from pathlib import Path
@@ -183,7 +183,7 @@ class BaseSurge(ABC):
         if batch:
             yield batch
 
-    def _resolve_file_path(self, path_input: Optional[str | Path] = None, extension: str = '.csv') -> Path:
+    def _resolve_file_path(self, path_input: Optional[Union[str, Path]] = None, extension: str = '.csv') -> Path:
         """
         Resolve an output file path from user input.
 

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/etl/bulk_surge.py

@@ -464,7 +464,7 @@ class BulkSurge(BaseSurge):
         logger.debug(f'sqlldr userid={user}/<PASSWORD>@{db} control={ctl_path} log={log_path}')
 
         try:
-            result = subprocess.run(cmd, capture_output=True, text=True)
+            result = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
 
             if result.returncode == 0:
                 logger.info("SQL*Loader completed successfully")
@@ -565,7 +565,7 @@ class BulkSurge(BaseSurge):
         else:
             cmd += ['-T',]  # integrated auth
         # Run BCP
-        result = subprocess.run(cmd, capture_output=True, text=True)
+        result = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
         if result.returncode != 0:
             error_msg = f"bcp failed with exit code {result.returncode}"
             if result.stderr:

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/etl/managers.py

@@ -606,7 +606,8 @@ class ValidationCollector:
             if self.desc_field:
                 return result.get(self.desc_field, "")
             for field in ("title", "description", "name", "label"):
-                if val := result.get(field):
+                val = result.get(field)
+                if val:
                     return val
             return str(result)
 

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/etl/table.py

@@ -63,7 +63,7 @@ class Table:
               'user_id': {'default': lambda: conf_vars['user_id']},
           }
 
-    * **fn** (callable | list[callable] | str, optional):
+    * **fn** (Union[callable, List[callable], str], optional):
       Transformation function(s) to apply to the source value.
       callable: applied directly; list: functions applied in order (pipeline);
       str: magic shorthand (e.g. 'int', 'maxlen:255', 'lookup:table:col:val').

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/etl/transforms/address.py

@@ -93,7 +93,7 @@ def _check_usaddress():
     if not HAS_USADDRESS:
         raise ImportError(
             "Address functionality requires the usaddress library. "
-            "Install with: pip install usaddress"
+            "Install with: pip install usaddress==0.5.10 (Python 3.6) or pip install usaddress (Python 3.7+)"
         )
 
 

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/logging_utils.py

@@ -76,6 +76,7 @@ def setup_logging(
     Example
     -------
     ::
+
         import dbtk
 
         # Simple - uses defaults from config

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/readers/base.py

@@ -151,7 +151,6 @@ class Reader(ABC):
 
     Common Features
     ---------------
-    * **Automatic header cleaning** - Standardize messy column names
     * **Row number tracking** - Automatic _row_num field for debugging
     * **Record skipping** - Skip header rows or bad data
     * **Record limiting** - Process only first N records
@@ -172,7 +171,7 @@ class Reader(ABC):
         Maximum number of rows to read. None (default) reads all rows.
     null_values : str, list, tuple, or set, optional
         Values to convert to None. Can be a single string or a collection of strings.
-        Common examples: '\\N' (IMDB files), 'NULL', 'NA', '' (empty string)
+        Common examples: '\\N', 'NULL', 'NA', '' (empty string)
 
     Example
     -------

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/readers/fixed_width.py

@@ -4,7 +4,7 @@
 
 import logging
 import os
-from typing import TextIO, List, Dict, Any, Optional, Iterator
+from typing import TextIO, List, Dict, Any, Optional, Iterator, Type
 
 from .base import Reader
 from ..record import Record, FixedWidthRecord
@@ -271,7 +271,7 @@ class EDIReader(FixedReader):
     def _get_columns(self, type_code: str) -> List[FixedColumn]:
         return self.columns.get(type_code)
 
-    def _get_factory(self, type_code: str) -> type[Record]:
+    def _get_factory(self, type_code: str) -> Type[Record]:
         if type_code not in self._type_factories:
             cols = self._get_columns(type_code)
             if cols is None:

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/writers/base.py

@@ -8,7 +8,7 @@ import logging
 import sys
 from abc import ABC, abstractmethod
 from pathlib import Path
-from typing import Any, BinaryIO, Iterable, Iterator, List, Optional, TextIO, Union
+from typing import Any, BinaryIO, Iterable, Iterator, List, Optional, TextIO, Tuple, Union
 
 from ..utils import RecordLike, to_string
 
@@ -170,7 +170,7 @@ class BaseWriter(ABC):
                 raise ValueError(f"{self.__class__.__name__} requires an output file path")
             self.output_path = Path(file)
 
-    def _open_file_handle(self, mode: str = "w") -> tuple[Union[TextIO, BinaryIO], bool]:
+    def _open_file_handle(self, mode: str = "w") -> Tuple[Union[TextIO, BinaryIO], bool]:
         """
         Open the output file/stream and return (handle, should_close).
 
@@ -181,7 +181,7 @@ class BaseWriter(ABC):
 
         Returns
         -------
-        tuple[Union[TextIO, BinaryIO], bool]
+        Tuple[Union[TextIO, BinaryIO], bool]
             (file_handle, should_close_flag)
         """
         if self.file is None:
@@ -267,7 +267,7 @@ class BaseWriter(ABC):
 
     def _get_data_iterator(
             self, data: Iterable[RecordLike], columns: Optional[List[str]] = None
-    ) -> tuple[Optional[Iterator], Optional[List[str]]]:
+    ) -> Tuple[Optional[Iterator], Optional[List[str]]]:
         """
         Get data iterator and column names.
 
@@ -280,7 +280,7 @@ class BaseWriter(ABC):
 
         Returns
         -------
-        tuple[Optional[Iterator], Optional[List[str]]]
+        Tuple[Optional[Iterator], Optional[List[str]]]
             (iterator, column_names)
         """
         if not data:

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk/writers/xml.py

@@ -7,7 +7,7 @@ import io
 import logging
 import re
 import sys
-from typing import Any, BinaryIO, List, Optional, TextIO, Union
+from typing import Any, BinaryIO, List, Optional, TextIO, Tuple, Union
 from pathlib import Path
 
 try:
@@ -196,7 +196,7 @@ class XMLStreamer(BatchWriter):
             preserve_types=True,  # We'll convert in _prepare_record_for_xml
         )
 
-    def _open_file_handle(self, mode: str = 'wb') -> tuple[BinaryIO, bool]:
+    def _open_file_handle(self, mode: str = 'wb') -> Tuple[BinaryIO, bool]:
         """
         Override to use binary mode and validate binary streams.
 
@@ -207,7 +207,7 @@ class XMLStreamer(BatchWriter):
 
         Returns
         -------
-        tuple[BinaryIO, bool]
+        Tuple[BinaryIO, bool]
             (file_handle, should_close_flag)
 
         Raises

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dbtk
-Version: 0.8.0
+Version: 0.8.2
 Summary: Data Benders Toolkit - A lightweight toolkit for data integration, ELT and ETL
 Author: Scott Bailey <scottrbailey@gmail.com>
 License: MIT
@@ -39,7 +39,8 @@ Requires-Dist: lxml>=4.6.0; extra == "recommended"
 Requires-Dist: openpyxl>=3.0.0; extra == "recommended"
 Requires-Dist: phonenumbers>=8.12.0; extra == "recommended"
 Requires-Dist: python-dateutil>=2.8.0; extra == "recommended"
-Requires-Dist: usaddress>=0.5.11; extra == "recommended"
+Requires-Dist: usaddress==0.5.10; python_version < "3.7" and extra == "recommended"
+Requires-Dist: usaddress>=0.5.11; python_version >= "3.7" and extra == "recommended"
 Provides-Extra: postgresql
 Requires-Dist: psycopg2-binary>=2.9; extra == "postgresql"
 Requires-Dist: psycopg[binary]>=3.1; extra == "postgresql"
@@ -57,7 +58,8 @@ Requires-Dist: openpyxl>=3.0.0; extra == "all"
 Requires-Dist: xlrd>=1.2.0; extra == "all"
 Requires-Dist: phonenumbers>=8.12.0; extra == "all"
 Requires-Dist: python-dateutil>=2.8.0; extra == "all"
-Requires-Dist: usaddress>=0.5.11; extra == "all"
+Requires-Dist: usaddress==0.5.10; python_version < "3.7" and extra == "all"
+Requires-Dist: usaddress>=0.5.11; python_version >= "3.7" and extra == "all"
 Provides-Extra: dev
 Requires-Dist: pytest>=6.0; extra == "dev"
 Requires-Dist: pytest-cov>=2.10; extra == "dev"
@@ -70,7 +72,7 @@ Dynamic: license-file
 # DBTK - Data Benders Toolkit
 
 <div style="float: right; padding: 20px">
-    <img src="/docs/assets/databender.png" height="240" align="right" />
+    <img src="https://raw.githubusercontent.com/scottrbailey/dbtk/main/docs/assets/databender.png" height="240" align="right" />
 </div>
 
 **Control and Manipulate the Flow of Data** - A lightweight Python toolkit for data integration, transformation, and movement between systems.
@@ -80,9 +82,9 @@ Extract data from various sources, transform it through powerful operations, and
 This library is designed by and for data integrators.
 
 **DBTK aims to be fast and memory-efficient at every turn.** But it was designed to boost your productivity first and foremost.
-You have dozens (possibly hundreds) of interfaces, impossible deadlines, and multiple projects all happening at once. Your
-environment has three or more different relational databases. You just want to get stuff done instead of writing the same
-boilerplate code over and over or stressing over differences on a database server you don't use very often.  
+You have dozens, possibly hundreds, of interfaces, impossible deadlines, and multiple projects all happening at once. Your
+environment has different relational databases, each has its own quirks. You just want to get stuff done instead of writing the same
+boilerplate code over and over.  
 
 **Design philosophy:** Modern databases excel at aggregating and transforming data at scale. DBTK embraces
 this by focusing on what Python does well: flexible record-by-record transformations,
@@ -93,6 +95,47 @@ your database handle it. If you need dataframes and heavy analytics - reach for
 or polars. DBTK sits in between: getting your data where it needs to be, cleaned and
 validated along the way.
 
+## Why DBTK?
+
+Most ETL tools fall into one of two traps:
+
+- **Verbose boilerplate hell** — SQLAlchemy + pandas + custom loops, repeated across every
+  interface with minor variations, slowly accreting defensive code for every edge case
+- **Opaque black box** — so much is hidden that debugging feels like reverse-engineering
+  someone else's code
+
+DBTK threads the needle. It's declarative enough to eliminate repetition, but explicit enough
+that you stay in control. When something breaks, you know exactly where to look.
+
+The architecture is intentionally layered — use what you need, skip what you don't:
+
+```
+Record          → ergonomic row handling, memory-efficient at scale
+Table           → field mapping, transforms, validation, upserts
+DataSurge       → batched inserts with progress tracking and stats
+BulkSurge       → direct bulk loads (SQL*Loader, BCP, COPY) for maximum throughput
+readers/writers → consistent API across every file format and compression type
+```
+
+When developers convert existing jobs to DBTK, the result can be **half to a quarter the
+original code**. That reduction comes from specific things DBTK just handles:
+
+- **Key column validation** — DBTK throws a clear error if a key field is missing from the source.
+  No more writing null-guards before every upsert.
+- **Safe partial updates** — if a field is missing from the source, DBTK excludes it from the
+  UPDATE rather than overwriting with NULL. No more "did I just wipe a column?" paranoia.
+- **Batch loop elimination** — DataSurge handles chunking, committing, retries, and statistics.
+  No more hand-rolled batch loops.
+- **Zero-config logging** — one line sets up timestamped log files with auto-cleanup and a global
+  error flag. No logging boilerplate scattered through your pipeline.
+- **TableLookup shorthand** — define a lookup or validation in ~40 characters:
+  `'fn': 'validate:ranks:rank_code:preload'`. The `preload` hint pre-caches the table before
+  processing starts. What would otherwise be a custom class or 30-line function is a string.
+
+The code that remains is shorter, clearer, and still has all the functionality and checks. You
+finish the job and think *"that was satisfyingly elegant"* — not because corners were cut, but
+because the tool was collaborating with you instead of making you fight it.
+
 **Speed and Memory** The primary objective of DBTK is to give data integrators an elegant toolkit to speed up your development.
 But DBTK's throughput and memory usage are very good. BulkSurge streaming from a polars and doing direct loads to PostgreSQL will
 process 1M rows in 3-4 seconds. But even with a standard Python csv reader and numerous column transforms, DataSurge is able to

{dbtk-0.8.0 → dbtk-0.8.2}/dbtk.egg-info/requires.txt

@@ -11,6 +11,11 @@ openpyxl>=3.0.0
 xlrd>=1.2.0
 phonenumbers>=8.12.0
 python-dateutil>=2.8.0
+
+[all:python_version < "3.7"]
+usaddress==0.5.10
+
+[all:python_version >= "3.7"]
 usaddress>=0.5.11
 
 [dev]
@@ -50,6 +55,11 @@ lxml>=4.6.0
 openpyxl>=3.0.0
 phonenumbers>=8.12.0
 python-dateutil>=2.8.0
+
+[recommended:python_version < "3.7"]
+usaddress==0.5.10
+
+[recommended:python_version >= "3.7"]
 usaddress>=0.5.11
 
 [sqlserver]

{dbtk-0.8.0 → dbtk-0.8.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "dbtk"
-version = "0.8.0"
+version = "0.8.2"
 description = "Data Benders Toolkit - A lightweight toolkit for data integration, ELT and ETL"
 readme = "README.md"
 requires-python = ">=3.6"
@@ -44,7 +44,8 @@ recommended = [
     "openpyxl>=3.0.0",
     "phonenumbers>=8.12.0",
     "python-dateutil>=2.8.0",
-    "usaddress>=0.5.11"
+    "usaddress==0.5.10;python_version<'3.7'",
+    "usaddress>=0.5.11;python_version>='3.7'"
 ]
 postgresql = ["psycopg2-binary>=2.9", "psycopg[binary]>=3.1"]
 oracle = ["oracledb>=1.0;python_version>='3.7'",  # For modern systems
@@ -59,7 +60,8 @@ all = [
     "xlrd>=1.2.0",
     "phonenumbers>=8.12.0",
     "python-dateutil>=2.8.0",
-    "usaddress>=0.5.11"
+    "usaddress==0.5.10;python_version<'3.7'",
+    "usaddress>=0.5.11;python_version>='3.7'"
 ]
 dev = ["pytest>=6.0", "pytest-cov>=2.10"]
 docs = [
@@ -76,5 +78,9 @@ Homepage = "https://github.com/scottrbailey/dbtk"
 Documentation = "https://dbtk.readthedocs.io"
 Repository = "https://github.com/scottrbailey/dbtk.git"
 
+[tool.setuptools.packages.find]
+where = ["."]
+include = ["dbtk*"]
+
 [tool.setuptools.package-data]
 dbtk = ["dbtk_sample.yml"]