virtualenv < 14installed always the embedded pip (the pip that was packaged with virtualenv),
14 <= virtualenv <= 16always downloaded the latest version from PyPi,
20 <= virtualenvtried to strike a middle ground: install the latest version available offline (by default this is the embedded, however, if someone pulls in a new version e.g. via a manual run that has
--downloadflag then in subsequent creations use the newer version).
The way I understand @dstufft champions the download by default is for to users always get the latest pip that allows:
- pip will not display in a newly created virtual environment the annoying message of there’s a newer version available
- easier role out of pip changes, as everyone gets it immediately (faster iteration on packaging ecosystem development).
Historically setuptools/wheel also benefited from these changes, however with PEP-518 they’re no longer anywhere as relevant (as the build frontend handles now their provision, and is less relevant what the virtual environment starts out with).
I and Anthony facilitated the behaviour change in
virtualenv 20 driven by our experience from the industry that most engineers priorities go along the order of reproducibility, speed and then ease of use. Always downloading the latest version from PyPi while helps with improving ease of use (as we can quickly improve the ecosystem as side effect by rolling out new changes quicker) it directly hurts both speed and reproducibility.
Anthony detailed war stories of how within Yelp they patched virtualenv to revert to the no download behaviour due to the amount of breakage this caused in their CIs. And I can second back this myself with experience from Bloomberg. The recent release of
pip broke two CIs of ours (by switching to in-place builds - a change since agreed to be reverted). Furthermore, a big plus of virtualenv 20 is how quick it is to build a virtual environment. By switching to always download would hurt this aspect too. Note virtualenv does a new release shortly after pip/setuptools/wheel does. So if someone upgrades virtualenv they will get newer versions of the packages too.
I proposed a middle-ground solution that would go along the lines of:
- always install the embedded version,
- check for upgrading the embed wheel once every two weeks and upgrade if there have been no releases in the last 10 days (the 10 day period is there to ensure the release is stable and does not contain major breaking changes).
I’m reaching out to the community to ask what you’re thinking? Which of the solutions do you prefer? Please vote in the poll and explain in responses below. Thanks!
- Speed and reproducibility all the way - always install the embedded wheel
- Force the latest release always - let’s roll out changes as quick as possible even if that breaks things
- The middle ground - always install embedded but check for upgrades every two weeks (and upgrade if no release in 10 days)