-
-
Notifications
You must be signed in to change notification settings - Fork 526
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
Comments
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 |
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. |
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 |
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 adddownload=true
to tox.ini.Some notes:
pip install -U pip
before tox didn't help.download
option having False as default is not following semver as it changes existing behavior (which was equivalent todefault=True
).The text was updated successfully, but these errors were encountered: