pyproject.toml declares packages = ["scripts"] under [tool.hatch.build.targets.wheel], but scripts/ has no __init__.py.
This works today because hatchling treats it as an implicit namespace package (PEP 420). But the behavior depends on hatchling version and on whether the installer supports namespace packages. It also means import scripts in a fresh venv after pip install -e . may silently import nothing (the namespace package has no attributes unless submodules are explicitly imported).
The dual-path try/except pattern in all client modules already handles this gracefully at runtime. But if someone runs python -c "import scripts; print(scripts.__file__)" expecting a real package, they will get None or an AttributeError.
Options:
- Add an empty
scripts/__init__.py to make it a regular package.
- Document in CONTRIBUTING.md that
scripts/ is a namespace package and direct imports should target specific submodules.
Option 1 is simpler and removes ambiguity.
pyproject.tomldeclarespackages = ["scripts"]under[tool.hatch.build.targets.wheel], butscripts/has no__init__.py.This works today because hatchling treats it as an implicit namespace package (PEP 420). But the behavior depends on hatchling version and on whether the installer supports namespace packages. It also means
import scriptsin a fresh venv afterpip install -e .may silently import nothing (the namespace package has no attributes unless submodules are explicitly imported).The dual-path try/except pattern in all client modules already handles this gracefully at runtime. But if someone runs
python -c "import scripts; print(scripts.__file__)"expecting a real package, they will getNoneor anAttributeError.Options:
scripts/__init__.pyto make it a regular package.scripts/is a namespace package and direct imports should target specific submodules.Option 1 is simpler and removes ambiguity.