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

Allow tox to use existing environment if no network connectivity #3310

Open
stephenfin opened this issue Jul 18, 2024 · 0 comments
Open

Allow tox to use existing environment if no network connectivity #3310

stephenfin opened this issue Jul 18, 2024 · 0 comments

Comments

@stephenfin
Copy link
Contributor

stephenfin commented Jul 18, 2024

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 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:

❯ tox -e py38 --no-provision
py38: recreate env because changed constraint(s) removed ...

[*] 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant