9da6fcd609
Currently, if we run with generate-constraints with a large number of
Python versions, we will get a large number of Python version specific
markers for dependencies: one for each passed Python version. For
example:
$ generate-constraints \
-b blacklist.txt \
-p /usr/bin/python3.8 \
-p /usr/bin/python3.9 \
-p /usr/bin/python3.10 \
-r global-requirements.txt
Will yield versions like:
networkx===3.1;python_version=='3.8'
networkx===3.2.1;python_version=='3.10'
networkx===3.2.1;python_version=='3.9'
What has happened here is that the given dependency (networkx in this
case) has dropped support for an older Python version (Python 3.8).
However, the way that we've specified this limits our constraints to the
versions of Python we ran (-p <python>) or the versions we mapped/mocked
(--version map <real:mapped[:mapped...]>). This isn't ideal. Instead, it
would be better to think in terms of upper and lower limits. That is, if
we generated a map like so:
networkx===3.1;python_version<='3.8'
networkx===3.2.1;python_version>='3.9'
This has the benefit of being simpler and potentially allowing us to
generate constraints for more Python versions than we currently check
for.
Change-Id: Ibfc6a79624e5591baf945a578f9d265071e57f73
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Global Requirements and Constraints for OpenStack Projects
Resources and Documentation
Please refer to the dependency management documentation linked below for up to date documentation on how to use and interact with the requirements project.