Paul has described the technical details behind this phenomenon, but to be more explicit: it is not pip that breaks older packages, but the new PyPI server (pypi.org instead of the old pypi.python.org) that does. So no, there is not a legacy mode in pip. Furthermore, you won’t be able to install the package now, even if you have the old pip version. The only way to overcome this is to find the original package, and either upload it to PyPI, or serve it yourself on your own server.

On 18/12/2018, at 22:05, Paul Moore <p.f.moore@gmail.com> wrote:

The PyPI index page for fcrypt (https://pypi.org/simple/fcrypt/) has no file links on it. I don't know why, but there's nothing there for pip to download.

The "Download" link points to a file not on PyPI - maybe that's the issue here, PEP 470 describes the process that was undertaken to remove external file hosting from PyPI (and the reasons behind doing so).

Paul

On Tue, 18 Dec 2018 at 13:55, Robin Becker <robin@reportlab.com> wrote:

...

I recently had to rebuild a server and find that pip 18.1 is apparently unable to install at least some older packages eg

...

$ bin/pip install fcrypt Collecting fcrypt Could not find a version that satisfies the requirement fcrypt (from versions: ) No matching distribution found for fcrypt

the version I needed is in fact the last released 1.3.1 (in 2004) and it was installed by an earlier pip. I tried being more explicit

...

$ bin/pip install fcrypt==1.3.1 Collecting fcrypt==1.3.1 Could not find a version that satisfies the requirement fcrypt==1.3.1 (from versions: ) No matching distribution found for fcrypt==1.3.1

I assume that latest pip needs information from the package / pypi data that is not available. Luckily installing from a pypi download works.

Is there any legacy mode in pip? It seems wrong to cause these older packages to become unusable. -- Robin Becker -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/FT6JK...

-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/UQD22...

On Tue, Dec 18, 2018 at 3:43 PM Tzu-ping Chung <uranusjr@gmail.com> wrote:

...

Paul has described the technical details behind this phenomenon, but to be more explicit: it is not pip that breaks older packages, but the new PyPI server (pypi.org instead of the old pypi.python.org) that does.

So no, there is not a legacy mode in pip. Furthermore, you won’t be able to install the package now, even if you have the old pip version.

well luckily for me clicking on the download link did in fact produce a tar zip so that at least allow me to install this defunct

On 18/12/2018 15:00, Joni Orponen wrote: package.

...

The only way to overcome this is to find the original package, and either upload it to PyPI, or serve it yourself on your own server.

I can do the last, but surely only the package owner can upload the tar zip.

When dealing with legacy setups, buildout still has most of the required machinery to make arcane things tick. If the file still exists, buildout can be configured to follow the links via explicit whitelisting of acceptable sources (and many a links of the bitrot variety are still available through being a tad lucky through archive.org - pre-stdlib inclusion elementtree eggs are a fine example of this).

http://www.buildout.org/en/latest/reference.html#buildout-configuration-opti...

The real solution is to dive in to maintain the package barely enough to upload a new release to PyPI, though.

so little time :( sigh I accept that the fcrypt issue is not a pip problem, but perhaps there's another related to the _vendor included version of pyopenssl. One of the recovered environments needed to install pyOpenSSL==16.0.0, but when that occurred it seems as though pip 18.1 breaks due to an incompatibility in the site-packages/OpenSSL that is then imported by site-packages/_vendor/urllib3/contrib/pyopenssl.py In the end the answer is to upgrade the environment's pyopenessl so that pip can at least work. I'm not exactly sure why there's a _vendor (this is ubuntu 18.04.1 LTS) thing, but it shouldn't be importing from a wrong/different OpenSSL. -- Robin Becker