Pin all dependencies with 'pip freeze'
Description
We aim to pin all the dependencies so we don't get broken by new versions of things. However, for some reason there are lots of transitive dependencies which haven't been pinned.
I ran pip freeze
on max-exfl016, in /home/xcal/deployments/development/git.xfel.eu/detectors/pycalibration/current/.venv
, and then fiddled with the order & spelling a bit to minimise the diff.
How Has This Been Tested?
These packages are the versions already installed on max-exfl016, so this shouldn't change anything that already works.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
Reviewers
Merge request reports
Activity
mentioned in merge request !592 (merged)
The downside of this is that when we update dependencies, their dependencies may change. E.g. we don't actually need Fabio; it's installed as a dependency of EXtra-data 1.4.1. When we upgrade to the latest EXtra-data, we could drop it from this list again. But that relies on us remembering that it's only there because of EXtra-data and we can safely remove it. There's also a similar problem if updated packages add dependencies, although at least that way we can
pip freeze
again to pick them up.There are plenty of solutions for this, where you can keep a list of the packages you directly require, and use that to build & update a bigger list of all the packages to install. But I want to ensure the docutils upgrade doesn't break our reports for now (see !592 (merged)).
Yup - e.g. Sphinx 1.8.5 doesn't pin a specific version of docutils, and now if you install the latest docutils, it breaks. Packages on PyPI don't usually have pinned dependencies, because e.g. if my package pins docutils 0.17 and yours pins 0.17.1, you wouldn't be able to install them in the same environment.
The rough idea is that libraries have dependency ranges, and then applications lock/freeze a specific version of all the libraries they need.
My leaning is to merge !592 (merged) to fix the immediate issue, leave this one, and figure out something cleverer for managing dependencies. I'm sure Robert will have some ideas.