Nice error message on pip 1.x when reading pip 6.0+ requirements.txt

[jayvdb]

pip 1.x is likely going to be present in default installs for a long time to come, as it is in all Debian releases.
https://packages.debian.org/search?keywords=python-pip

Currently 1.x can throw an ValueError if new requirements.txt features (e.g. environment specifiers) are used
(i.e. https://pip.pypa.io/en/latest/reference/pip_install.html#requirements-file-format vs https://pip.readthedocs.org/en/1.1/requirements.html)

It would be nice if pip 1.x detected the requirements.txt is not supported, and suggest to the user upgrade their pip.

A few implementation ideas:

• change the 1.x parser to recognise any syntax differences in the new file format.
• allow a file format version to be specified within the requirements.txt file as a comment.
• specify the required pip version within file as the first requirement. i.e. pip>=6 , which would also provide some reasonable meaning for the use of pip within requirements.txt ( see issue pip install -r requirements.txt with pip inside, will get pip uninstalled #1656 ).

[rbtcollins]

So the bug title asks for this on 'stable', but the current stable release is 7.1 : 1.x is ancient history.

The fundamental problem here BTW isn't doing the work, its getting into the various distros: if they're willing to change their package, they could just pull in a newer pip.

[jayvdb]

@rbtcollins , I've updated the issue title to avoid 'stable'. 1.x is far from ancient history if that is what all Debian versions provide.

I agree with you that writing the code for this issue isnt the hard part. Pushing it into distros is hard. Maintainers of distro packages will be much more inclined to update their package to a new minor version number if it includes minimal changes, than jump to a new major version number. Ideally the code for 1.x would be very minimal to improve the changes that distro package maintainers feel it is a low risk version change. If the pip maintainers are unwilling to release a new 1.x, then this issue cant be solved for 1.x, as distro package maintainers are unlikely to pick up the fix unless it is properly released by the pip maintainers.

However even if this problem cant be solved for 1.x, there is still the underlying problem that there is currently no way to cleanly alter the requirements.txt file format in the future in a way that old versions of pip can differentiate between 'invalid syntax' and 'unsupported syntax'.

[tritium21]

I think the recommendation here is to educate users on removing debian provided versions of pip and setuptools, and instead get them to install pip (and setuptools, and wheel, etc) with --user. This is a rather sane option; If a .deb actually depends on pip for the functionality of pip, then that debian package is rather insane. If you are deploying .debs in house that require the functionality of pip, thats kind of silly - if you are going through that trouble, save yourself the headache and package your dependencies yourself or use the apt provided versions.

The best solution, by far, is to get the distros to NOT package pip, but to bootstrap pip the way the stdlib module ensurepip bootstraps pip.

[warsaw]

I'd say it's unlikely to get backported into stable Debian (not to mention Ubuntu) releases unless it fixes a critical bug as listed here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python-pip;dist=unstable or https://bugs.launchpad.net/ubuntu/+source/python-pip

I'm not sure this rises to that level, but let's say it does. In that case I don't think we'd need a new pip release. Better would be an upstream blessed patch that applies cleanly to the existing Debian/Ubuntu packages as a quilt patch. We could cherry pick that from pip's vcs, or better, the above mentioned hypothetical bug would include a debdiff.

[dstufft]

Ok, given that the primary reason to be using an older pip is because you're using a Linux distribution or some other package manager which won't pull in newer versions of a package except in specific scenarios I'm going to go ahead and close this issue. I don't think that any of the downstream folks are going to pull in a patch for this.