Skip to content
Snippets Groups Projects

Pin all dependencies with 'pip freeze'

Closed Thomas Kluyver requested to merge freeze-deps into master
2 unresolved threads

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

@danilevc @roscar

Merge request reports

Checking pipeline status.

Approval is optional

Closed by Thomas KluyverThomas Kluyver 3 years ago (Oct 27, 2021 4:10pm UTC)

Merge details

  • The changes were not merged into master.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Thomas Kluyver mentioned in merge request !592 (merged)

    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)).

    • Why would you pin the dependencies of dependencies in the first place? To account for them not being pinned themselves?

    • 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.

    • Please register or sign in to reply
Please register or sign in to reply
Loading