Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package upgrades post virtualenv creation by default should be off #448

Closed
asottile opened this issue Feb 3, 2017 · 19 comments · Fixed by #1283
Closed

package upgrades post virtualenv creation by default should be off #448

asottile opened this issue Feb 3, 2017 · 19 comments · Fixed by #1283

Comments

@asottile
Copy link
Member

@asottile asottile commented Feb 3, 2017

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
Copy link

@epu epu commented Feb 10, 2017

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
Copy link
Member Author

@asottile asottile commented Feb 10, 2017

Here's some related issues:

@epu
Copy link

@epu epu commented Feb 11, 2017

Thanks, now following along.

@asottile
Copy link
Member Author

@asottile asottile commented Apr 29, 2017

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

@hynek
Copy link
Contributor

@hynek hynek commented Jun 1, 2017

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

@obestwalter
Copy link
Member

@obestwalter obestwalter commented Jun 2, 2017

Any thoughts about getting that plugin into core?

@asottile
Copy link
Member Author

@asottile asottile commented Jun 2, 2017

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
Copy link
Member

@obestwalter obestwalter commented Jun 2, 2017

@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
Copy link
Member Author

@asottile asottile commented Jun 2, 2017

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
Copy link
Member

@gaborbernat gaborbernat commented Jul 3, 2018

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
Copy link
Member Author

@asottile asottile commented Jul 3, 2018

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
Copy link
Member

@gaborbernat gaborbernat commented Jul 3, 2018

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

@gaborbernat gaborbernat changed the title RFC: Enable users to have repeatable virtualenv creation (either VIRTUALENV_NO_DOWNLOAD or PIP_INDEX_URL) package upgrades post virtualenv creation by default should be off Jul 3, 2018
@gaborbernat gaborbernat added this to the 3.2 milestone Jul 3, 2018
@asottile
Copy link
Member Author

@asottile asottile commented Jul 3, 2018

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

@gaborbernat
Copy link
Member

@gaborbernat gaborbernat commented Jul 3, 2018

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
Copy link
Member

@obestwalter obestwalter commented Jul 3, 2018

Have a nice vacation @asottile!

@gaborbernat gaborbernat removed this from the 3.2 milestone Sep 14, 2018
@gaborbernat gaborbernat added this to the 3.4 milestone Sep 14, 2018
@gaborbernat
Copy link
Member

@gaborbernat gaborbernat commented Sep 14, 2018

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

@asottile
Copy link
Member Author

@asottile asottile commented Sep 14, 2018

feel free to take this!

@gaborbernat gaborbernat self-assigned this Sep 14, 2018
@gaborbernat gaborbernat removed this from the 3.4 milestone Sep 18, 2018
@gaborbernat gaborbernat added this to the 3.5 milestone Sep 18, 2018
@gaborbernat
Copy link
Member

@gaborbernat gaborbernat commented Sep 18, 2018

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.

@gaborbernat gaborbernat removed this from the 3.5 milestone Oct 8, 2018
@gaborbernat gaborbernat added this to the 3.6 milestone Oct 8, 2018
@gaborbernat gaborbernat removed this from the 3.6 milestone Oct 8, 2018
@gaborbernat gaborbernat added this to the 3.6 milestone Oct 8, 2018
@gaborbernat gaborbernat removed this from the 3.6 milestone Dec 16, 2018
@gaborbernat gaborbernat added this to the 3.7 milestone Dec 16, 2018
@jaraco
Copy link
Contributor

@jaraco jaraco commented Apr 24, 2019

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

6 participants