ccb67adf94
Recently pydot3 was introduced which was a fork of pydot introducing Python 3.x compatibility. Since then pydot has added python 3.x support and seems to be more regularly releasing than pydot3, which hasn't seen a single release since two years. Furthermore networkx is actually requiring pydot and will refuse to run with pydot3 installed so there isn't much choice. Is the library actively maintained? Last release Dec 25, 2017 and no indications of project being abandoned. Is the library good code? Merging the pydot3 changes it should be as good as the pydot3 addition. Is the library license compatible? Yes. Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)? Yes. Is the function of this library already covered by other libraries in global-requirements.txt? It was covered by pydot3 which this one is superseding. Is the library required for OpenStack project or related dev or infrastructure setup? (Answer to this should be Yes, of course) Which? Taskflow needs pydot for executing its networkx graph generation unit test. If the library release is managed by the Openstack release process does it use the cycle-with-intermediary release type? No. Change-Id: Ie0607c86259bda5483b2bf4f6f9a87f93cd9be0e
Global Requirements for OpenStack Projects
Why Global Requirements?
Refer to the Dependency Management section of the Project Team Guide for information about the history of the project and the files involved.
Tools
All the tools require openstack_requirements to be installed (e.g. in a Python virtualenv). They all have help, which is the authoritative documentation.
update-requirements
This will update the requirements in a project from the global
requirements file found in .. Alternatively, pass
--source to use a different global requirements file:
update-requirements --source /opt/stack/requirements /opt/stack/novaEntries in all requirements files will have their versions updated to match the entries listed in the global requirements. Excess entries will cause errors in hard mode (the default) or be ignored in soft mode.
generate-constraints
Compile a constraints file showing the versions resulting from
installing all of global-requirements.txt:
generate-constraints -p /usr/bin/python2.7 -p /usr/bin/python3 \
-b blacklist.txt -r global-requirements.txt > new-constraints.txtedit-constraints
Replace all references to a package in a constraints file with a new specification. Used by DevStack to enable git installations of libraries that are normally constrained:
edit-constraints oslo.db "-e file://opt/stack/oslo.db#egg=oslo.db"build-lower-constraints
Combine multiple lower-constraints.txt files to produce a list of the highest version of each package mentioned in the files. This can be used to produce the "highest minimum" for a global lower constraints list (a.k.a., the "TJ Maxx").
To use the script, run:
$ tox -e venv -- build-lower-constraints input1.txt input2.txtWhere the input files are lower-constraints.txt or requirements.txt files from one or more projects.
If the inputs are requirements files, a lower constraints list for the requirements is produced. If the inputs are lower-constraints.txt, the output includes the highest version of each package referenced in the files.
check-requirements
Run the validation checks from the requirements-check
job locally using the requirements-check tox
environment.
Run:
$ tox -e requirements-check -- /path/to/repo/to/testProposing changes
Look at the Review Guidelines and make sure your change meets them.
All changes to global-requirements.txt may dramatically
alter the contents of upper-constraints.txt due to adding
or removing transitive dependencies. As such you should always generate
a diff against the current merged constraints, otherwise your change may
fail if it is incompatible with the current tested constraints.
Regenerating involves five steps.
Install the dependencies needed to compile various Python packages:
sudo apt-get install $(bindep -b)Create a reference file (do this without your patch applied):
generate-constraints -p /usr/bin/python2.7 -p /usr/bin/python3 \ -b blacklist.txt -r global-requirements.txt > baselineApply your patch and generate a new reference file:
generate-constraints -p /usr/bin/python2.7 -p /usr/bin/python3 \ -b blacklist.txt -r global-requirements.txt > updatedDiff them:
diff -p baseline updatedApply the patch to
upper-constraints.txt. This may require some fiddling.edit-constraintcan do this for you when the change does not involve multiple lines for one package.