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

download=false breaks AppVeyor #1302

Closed
akosthekiss opened this issue May 15, 2019 · 3 comments
Closed

download=false breaks AppVeyor #1302

akosthekiss opened this issue May 15, 2019 · 3 comments
Labels
bug:normal affects many people or has quite an impact

Comments

@akosthekiss
Copy link

The new feature of version v3.10.0, i.e., to disable the automatic upgrade of pip/wheels/setuptools in the created virtual environment (#448), breaks AppVeyor completely. We have experienced this in our project, where everything worked perfectly 7 days ago, while triggering a new CI job for the same commit caused AppVeyor go red today. It has turned out that the difference between the two runs was that the earlier job used tox 3.9 while the job of today used 3.11 (and so it called virtualenv with --no-download). The only solution I've found was to add download=true to tox.ini.

Some notes:

  • No problem on Travis CI.
  • Running pip install -U pip before tox didn't help.
  • It seems to me that the new download option having False as default is not following semver as it changes existing behavior (which was equivalent to default=True).
@akosthekiss akosthekiss added the bug:normal affects many people or has quite an impact label May 15, 2019
@akosthekiss akosthekiss changed the title download=true breaks AppVeyor download=false breaks AppVeyor May 15, 2019
@gaborbernat
Copy link
Member

If you want the download option, yes set it to True. Alternatively use force reinstall flag on pip when installing tox to ensure a newer virtualenv is installed alongside. Appveyor ships an ancient 8.0 version of virtualenv

@akosthekiss
Copy link
Author

Would you mind giving the command you suggested as the alternative? I'm not sure I know what parametrization of which command you meant.

PS: Ancient virtalenv or not, I didn't expect a minor version bump to change and break things. Tox quite prominently states that it is following Semantic Versioning. Such a change is against those rules IMHO.

@gaborbernat
Copy link
Member

gaborbernat commented May 16, 2019

It's not tox breaking you, but rather the fact you're using features of pip/setuptools that are not present with an older bundled virtualenv. Did you define your pip/setuptools version constraints accurately?

pip install tox -U --force-reinstall

Changing to download false makes on one end builds repeatable (a sudden new broken release of pip/setuptools no longer breaks you). Plus it forces users to define accurately their pip/setuptools/wheels dependencies.

Alternatively you can get back the old behaviour via:

[testenv]
download = True

The change in behaviour (https://tox.readthedocs.io/en/latest/changelog.html#v3-10-0-2019-05-13) is to fix #448

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug:normal affects many people or has quite an impact
Projects
None yet
Development

No branches or pull requests

2 participants