Build artifacts and optional dependencies of the Python package

[jenstroeger]

Current approach

As of v2.3.3 of this package template, the pyproject.toml file declares no package dependencies

python-package-template/pyproject.toml

Line 14 in 25c486b

dependencies = []

and a handful of optional/extra dependencies

python-package-template/pyproject.toml

Lines 36 to 63 in 25c486b

	[project.optional-dependencies]
	# The 'actions' requirements match exactly the packages installed by the workflows.
	# We keep them listed here to ensure the infrastructure BOM is consistent with what's
	# installed. Make sure to keep the requirements in sync with the workflows!
	actions = [
	"commitizen ==2.32.1",
	"twine ==4.0.1",
	]
	dev = [
	"flit >=3.2.0,<4.0.0",
	"mypy >=0.921,<=0.971",
	"pylint >=2.9.3,<=2.14.5",
	"cyclonedx-bom >=3.5.0,<4.0.0",
	]
	docs = [
	"sphinx >=5.1.1,<6.0.0",
	]
	hooks = [
	"pre-commit >=2.18.0,<=2.20.0",
	]
	# Note that the `custom_exit_code` and `env` plugins may currently be unmaintained.
	test = [
	"hypothesis >=6.21.0,<=6.54.4",
	"pytest >=7.1.2,<8.0.0",
	"pytest-custom_exit_code ==0.3.0",
	"pytest-cov ==3.0.0",
	"pytest-env ==0.6.2",
	]

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…

1. What if the shipping package declares one or more optional/extra dependencies, and thereby introduces different variations of itself?
2. 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?
3. 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… 🤔