Context
Discovered during review of PR #229 (Docker rework) and smartem-devtools PR DiamondLightSource/smartem-devtools#166.
Current state
setup.py hooks into three setuptools commands (install, develop, egg_info) to do two things:
copy_version_files() — Copies src/_version.py to each sub-package (smartem_backend, smartem_agent, smartem_common, smartem_api)
copy_dotenv() — Copies .env.example to .env if .env doesn't exist
Why it may be unnecessary
copy_version_files() is redundant
setuptools-scm already handles version file generation via the [tool.setuptools_scm] version_file config in pyproject.toml. The setup.py hook duplicates this work. Verified empirically: Docker builds produce correct _version.py files without the setup.py hook firing.
copy_dotenv() is a minor convenience with limited reach
- Only reliably works in editable installs (
pip install -e .) on the host
- Does not fire reliably during PEP 517 wheel builds (which is what
pip install ., uv, and Docker builds use)
.dockerignore excludes .env.example (matches .env.*), so it never enters Docker build context — verified empirically
- Could be replaced by a note in README or a Makefile target
cmdclass hooks are a legacy mechanism
Modern Python packaging (PEP 517/518) uses build backends that don't necessarily invoke setuptools command classes. The hooks work in editable installs but are unreliable in standard installs.
Related
What to investigate
- Can
setup.py be deleted entirely?
- Is there a better mechanism for the
.env.example → .env convenience (e.g. documented manual step, Makefile)?
- Are there any other consumers of the
cmdclass hooks?
- Does the duplicate
.env.example in smartem-decisions still serve a purpose if setup.py is removed? (identical copy exists in smartem-devtools/env-examples/)
Context
Discovered during review of PR #229 (Docker rework) and smartem-devtools PR DiamondLightSource/smartem-devtools#166.
Current state
setup.pyhooks into three setuptools commands (install,develop,egg_info) to do two things:copy_version_files()— Copiessrc/_version.pyto each sub-package (smartem_backend,smartem_agent,smartem_common,smartem_api)copy_dotenv()— Copies.env.exampleto.envif.envdoesn't existWhy it may be unnecessary
copy_version_files()is redundantsetuptools-scmalready handles version file generation via the[tool.setuptools_scm] version_fileconfig inpyproject.toml. The setup.py hook duplicates this work. Verified empirically: Docker builds produce correct_version.pyfiles without the setup.py hook firing.copy_dotenv()is a minor convenience with limited reachpip install -e .) on the hostpip install .,uv, and Docker builds use).dockerignoreexcludes.env.example(matches.env.*), so it never enters Docker build context — verified empiricallycmdclasshooks are a legacy mechanismModern Python packaging (PEP 517/518) uses build backends that don't necessarily invoke setuptools command classes. The hooks work in editable installs but are unreliable in standard installs.
Related
What to investigate
setup.pybe deleted entirely?.env.example→.envconvenience (e.g. documented manual step, Makefile)?cmdclasshooks?.env.examplein smartem-decisions still serve a purpose if setup.py is removed? (identical copy exists insmartem-devtools/env-examples/)