package upgrades post virtualenv creation by default should be off

[asottile]

In virtualenv 15, virtualenv by default attempts to upgrade pip, setuptools, and wheel while creating a virtualenv. It does this by using whatever PIP_INDEX_URL is set (or doesn't at all if --no-download or VIRTUALENV_NO_DOWNLOAD is set).

In my ideal world, I'd love for tox to default to VIRTUALENV_NO_DOWNLOAD=1, but I can see why that may be surprising or not a popular choice (since it would differ from the choice made in pypa/virtualenv). The main reason I want this is to have repeatable builds without being surprised by external factors changing / going down (pypi goes down pretty frequently! and setuptools upgrades pretty frequently (and breaks things too often)).

Since this is probably not reasonable, I think a good compromise would be to export PIP_INDEX_URL=tox['indexserver']['default'] if provided -- this would solve our primary concern and ensure repeatable builds given the state of our index server.

[epu]

Thanks for filing this ticket. I have tests in some of my work that pin the version of six, and the uninstall of six to the older version caused my tox testenv deployment to fail. I hadn't figured out after pinning all my versions explicitly where the issue was happening, but the virtualenv creation itself was my next target. Setting the VIRTUALENV_NO_DOWNLOAD in my testenv environment fixed everything for me for one of my testenvs.

[asottile]

Here's some related issues:

• Installing six<1.10 breaks fresh virtualenv pypa/virtualenv#1009
• Setuptools 34.0.2 breaks new virtual envs with six < 1.10 pypa/setuptools#947

[epu]

Thanks, now following along.

[asottile]

I made a plugin to turn virtualenv's behaviour off entirely: https://github.com/asottile/tox-virtualenv-no-download

[hynek]

Since Travis is currently on 🔥 due to a setuptools ooops, we might want to revisit this issue. :)

[obestwalter]

Any thoughts about getting that plugin into core?

[asottile]

I'd love to contribute it to core, currently the plugin is not configurable (always disabling the behavior), I'd imagine we would want some sort of way to toggle it in tox.ini?

I guess the main sticking point would be if tox is willing to choose a default of no download (despite the choice made in virtualenv) or not.

[obestwalter]

@asottile I agree - these points need to be clarified before we could get it in.

I think we should try to respect the principle of least surprise. To me that would mean that default should be the same as in virtualenv with as good as a helpful error message we can manage if something related to that goes wrong.

[asottile]

Yeah I'm going to try and see what I can do to change virtualenv's default too. At least for companies / enterprise, downloading is a pretty not great default (so there may continue to be a need for the plugin even when integrating this feature as a way to blanket change the default).

[gaborbernat]

So a year later, @asottile are we ready to make this into core; maybe with some flag of [tox] new_env_upgrade_pip_wheel_setuptools = False?

[asottile]

I use it everywhere and haven't run into any issues yet: https://github.com/asottile/personal-puppet/blob/890a67845c8530f0548e7413776b82598b0703a1/modules/desktop/manifests/venv.pp#L4

there of course will be some consumers of tox with an ~oldish virtualenv (say, 14.x) that are depending on pip 9 features that it could break

I really like the idea of VIRTUALENV_NO_DOWNLOAD by default -- I think this is the best situation for repeatable builds. The question then becomes how to turn that behaviour off if --download is desirable 😆 . I think your suggestion option name works fine though I'd lean more towards matching the upstream option name if possible (virtualenv_download = True?)

[gaborbernat]

I'm fine with that. Do you have the availability to open a PR for it?

[asottile]

about to take a vacation -- might get to it but no promises 🎆 🎆 🎆

[gaborbernat]

Hehe, no problems if you don't get to it in the next two weeks I might give it a go. No worries and enjoy!

[obestwalter]

Have a nice vacation @asottile!

[gaborbernat]

@asottile can you pick this up now, or should I go ahead with it?

[asottile]

feel free to take this!

[gaborbernat]

Given this is a major change so to say moved this into the scope of 3.5 version. We already have enough going on inside 3.4.

[jaraco]

This ticket should also link to tox-dev/tox-venv#25, which promises to bring the auto-upgrade behavior to venv-based tox builds.