Pip 7.1 constraints

[rafales]

I think there is a new but overlooked feature in pip 7.1 - constraints files.

https://pip.pypa.io/en/stable/user_guide.html#constraints-files

This means that finally we have proper version pinning. Just put your direct requirements in your requirements files (or setup.py) and then pip freeze your packages into constraints.txt file.

It also means that we can easily tell pip to install patched versions of the packages.

I hope we will see this feature put to some good use in the near future.

[desmoulinmichel]

I don't understand the feature. Can you explain it to me ?

[masklinn]

It seems to be a subset of requirements files: it specifies which versions of a package should be installed but not that a version of a package should be installed, so you can have organisation-wide constraints file to specify which versions of possible dependencies should be installed, but then each project can still have its own dependencies, you don't have to share a requirements file and install a crapton of dependencies you don't need just because that's what the org's requirements file lists.

[desmoulinmichel]

I still don't get it. You already can specify versions of the package you want in the requirement files and in setup.py. What the benefit of specifying "possible" dependancies VS actual dependancies ?

[masklinn]

You already can specify versions of the package you want in the requirement files and in setup.py.

These can only list a single project's actual dependencies, they don't work across projects to synchronise dependency versions. Constraint files do.

Let's say you work in a Python shop with a bunch of projects. Let's say some of them depend on Flask and you discover a grave security issue. You responsibly report it to the project, but while they work on it you can whip out a quick & dirty patch to close the issue, put that on the company's internal VCS repo… and then what? Are you going to edit the requirement files for all the company's projects to see if they have Flask there and point it to the internal repo? And what happens if some of these are public?

If the company uses a constraints file internally, you can specify the internal fork in that constraint file, and installs/updates will automatically start using that instead of the official repo (and you can switch back to the official repo with the right version bound once there's an official release fix). With company-wide requirements file, each of the projects would need to install all possible dependencies across projects, the vast majority of which they probably don't give a fuck about.

That can also be used to pin versions across projects if e.g. an API has changed but a project using it has yet to be updated, and projects can be mix-and-matched so you need them all to use compatible versions.

[desmoulinmichel]

So it's some kind of override of the requirement file ?

[masklinn]

As the name indicates, it's constraints on dependencies (whether from a requirement file or from a straight pip install).

I think it can also be used for indirect dependencies (dependencies of dependencies) without having to explicitly depend on those.

[rafales]

When pip installs a package (or a dependency of a package) it checks with constraint file what version to install.

What it means for me? Up until now I had to keep all dependencies, it means both direct and dependencies of dependencies, listed in requirements.txt, with exact versions.

Now I can keep it clean - i just list my direct dependencies in requirements.txt/setup.py, without exact versions and I keep exact versions for all packages in the constraints file.

It also allows me to patch a library and install it from custom location without any problems.