You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tox - especially v4, with it's vastly improved dependency checking - is heavily reliant on good network connectivity to resolve dependencies. If you have poor/limited internet connectivity - such as when travelling or working from your local cafe ☕ - tox can take an age to get to the point of running tests, assuming it ever gets there. This happens regardless of how recently the environment was built [*].
Describe the solution you'd like
If tox (and by tox I probably mean the underlying pip install invocations) is unable to connect to the internet but a virtualenv already exists for the given target, tox could warn the user and then run commands using the existing virtualenv as a best effort. Alternatively, I could pass a flag to skip the env recreate check (though it should still reinstall the package under test). Something like the opposite of the --notest flag.
Alternative Solutions
My current workaround to this is to just use the virtualenv directly, e.g.:
source .tox/py310/bin/activate
stestr run ...
I can continue to do this, of course, but it would be nice to avoid having to copy/paste commands and resolve any expansions manually.
Additional context
I am happy to work on this myself at some point and consider this a low-priority nice-to-have. I just want to make sure it'll be welcomed if I do the work (and, ideally, get a heads up if this already exists or is simply not possible) 🙏
I did try the --no-provision flag, but that appears to be for preventing creation of the virtualenv: not controlling when stuff gets installed in there. Certainly when I try using it with an old, pre-existing testenv I see things getting recreated:
[*] Yes, I know this is totally expected and you can't resolve deps without lookup to PyPI or network calls to resolve e.g. remote constraints files. My point is that, as a user, a relatively recent build is probably "good enough", especially if the alternative is to not run anything.
The text was updated successfully, but these errors were encountered:
What's the problem this feature will solve?
tox
- especially v4, with it's vastly improved dependency checking - is heavily reliant on good network connectivity to resolve dependencies. If you have poor/limited internet connectivity - such as when travelling or working from your local cafe ☕ -tox
can take an age to get to the point of running tests, assuming it ever gets there. This happens regardless of how recently the environment was built [*].Describe the solution you'd like
If
tox
(and bytox
I probably mean the underlyingpip install
invocations) is unable to connect to the internet but a virtualenv already exists for the given target,tox
could warn the user and then run commands using the existing virtualenv as a best effort. Alternatively, I could pass a flag to skip the env recreate check (though it should still reinstall the package under test). Something like the opposite of the--notest
flag.Alternative Solutions
My current workaround to this is to just use the virtualenv directly, e.g.:
I can continue to do this, of course, but it would be nice to avoid having to copy/paste commands and resolve any expansions manually.
Additional context
I am happy to work on this myself at some point and consider this a low-priority nice-to-have. I just want to make sure it'll be welcomed if I do the work (and, ideally, get a heads up if this already exists or is simply not possible) 🙏
I did try the
--no-provision
flag, but that appears to be for preventing creation of the virtualenv: not controlling when stuff gets installed in there. Certainly when I try using it with an old, pre-existing testenv I see things getting recreated:[*] Yes, I know this is totally expected and you can't resolve deps without lookup to PyPI or network calls to resolve e.g. remote constraints files. My point is that, as a user, a relatively recent build is probably "good enough", especially if the alternative is to not run anything.
The text was updated successfully, but these errors were encountered: