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).