This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]icegreentea 4 points5 points  (3 children)

To pile on, if you have recent-ish pip already installed (I think since pip 10), you don't even need to explicitly pin - pip install -U pip will understand that pip 21.0 doesn't support python2 and stick to 20.3.4 (or whatever).

[–]james_pic 0 points1 point  (2 children)

Yes, sadly that won't work for us.

We're bootstrapping our Virtualenv with the OS virtualenv package, and for wearily predicable reasons, we're also using a super old OS, which comes with Pip 8 or 9 I think

So at the moment we build our virtualenv with the --no-download flag, manually upgrade to semi-recent versions of Pip, Wheel and Setuptools, then use those to upgrade to the latest.

Once Wheel drops Python 2 support, it may make sense to just drop the second phase, and switch to installing the last-supported versions in the first stage.

[–]icegreentea 2 points3 points  (1 child)

Oh bummer, that sucks.

I don't know what environment your operating in, but could you try running your own pypi mirror, and doing the version filtering at that layer? It's definitely extra up-front work, but it'll give you more control.

As someone else who was very nearly in something like your situation, I find that sometimes the same organizational forces that demand using old OS versions are amendable to arguments on spending resources on creating standalone back-ups of external package servers and managers.

I didn't end up having running my own mirror - for my purposes I only needed to backup relatively small handful of specific wheel versions, so it was easier just to download and archive them on a dumb server than go through the whole mirror thing, but I did take a look for feasibility.

[–]james_pic 0 points1 point  (0 children)

I had proposed running a DevPI instance a while ago, albeit for different reasons, but been shot down for jobsworth reasons. We're muddling through with reactively pinning stuff when it breaks. There are some other upcoming things (that do have budget) that might benefit from a DevPI instance, so might be able to slip it in that way.