jenstroeger
Build artifacts and optional dependencies of the Python package
Current approach
As of v2.3.3 of this package template, the pyproject.toml file declares no package dependencies
https://github.com/jenstroeger/python-package-template/blob/25c486b68d04c813c9bd366b44db858e20d281e4/pyproject.toml#L14
and a handful of optional/extra dependencies
https://github.com/jenstroeger/python-package-template/blob/25c486b68d04c813c9bd366b44db858e20d281e4/pyproject.toml#L36-L63
solely for the purpose of local development and CI/CD. However, it does not declare any optional/extra dependencies which would be considered part of the shipping & deployed package!
And because it does not declare any optional/extra dependencies, the generated release artifacts contain an almost empty requirements.txt file and an SBOM with pinned development dependencies only.
More complex packages
Naturally we want to build more complex packages which may even offer optional/extra dependencies, just like e.g. the Dramatiq or SQLAlchemy packages do. So, the questions that arise now are…
- What if the shipping package declares one or more optional/extra dependencies, and thereby introduces different variations of itself?
- What if installing one optional/extra requirement imposes different version constraints of dependent packages than another, thus changing a package that’s deeper down the dependency tree?
- What if some optional/extra requirements are mutually exclusive?
How would that impact the generation of the requirements.txt and SBOM artifacts? Not sure it makes sense to generate build artifacts for all possible variations of a package, nor build artifacts that are all-inclusive? Should we take a “best effort” approach? Or… 🤔
