-
-
Notifications
You must be signed in to change notification settings - Fork 512
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
Re-use of virtual environments across envs in tox4 #2788
Comments
Thanks for the extensive bug report. I am pretty sure we had this discussion quite recently, but I cannot find it again. From what I recall is that re-use of environments worked for tox v3 by chance, so was never officially supported. Even as this is not a planned change of behavior, this should be still listed in the mentioned faq. Waiting for @gaborbernat to confirm, and maybe he recalls the issue where this was discussed. FWIW there is also a very old issue where it was mentioned that re-use of environments is not supported by tox core, but could be supported by a plugin, see #425 Keeping this issue open until at least the faq is updated. |
And FWIW.. the usual way to define what you want is...
This all said, you could also have a look at https://pre-commit.com/ to run your linters, which is very common in the Python community.
|
This was never actually supported, worked only by chance because our env detection logic wasn't good enough. We don't plan to support this behavior. |
I'll add an entry to the faq/changes list later today. |
I've published a plugin to support this workflow as tox-ignore-env-name-mismatch |
Thank you @masenf!!! |
I'll just say that the core team does not agree with the approach taken, and we don't plan to offer support for the interface used to create this, but we'll not disallow it either 👍 in practice it means if you submit a bug to tox and you're using this plugin you're on your own 🙂 we'll close the issue without addressing the issue you're running into. |
Is this referring to |
The former, it's private for a reason. Also note that we don't really support sidestepping a core check of the tool, even if the python language allows it. 😅 |
It is a smart workaround of the problem though, just not an elegant solution to the underlying problem 😎 |
When test environments share the same basepython and requirements, might want to optimize the build by having the environment directory shared between the test environments. That was however never officially supported by tox v3: tox-dev/tox#425 (comment) and tox v4 explicitly breaks that assumption by comparing the environemtn based on the name of the test env (which prevents them from being shared): tox-dev/tox#2788 There is a plugin to filter out the test environment `name` from the configuration when doing the comparison: https://github.com/masenf/tox-ignore-env-name-mismatch But I don't want to require that plugin to run tox. As part of the switch to tox v4 (6b8a8f0) I also had to add a hack to allow tox v3 to provision tox v4 which was to set the environment directory to `.pkg` for the special `.tox` environment. That felt like a hack and is potentially fragile. Unless a solution is found in tox v4 (rather than via a plugin), remove the envdir configuration and the now useless tox v3 back compatibility bit. This will cause multiple identical environments to be created initially, they should be quite fast though since they reuse wheels from the cache. Bug: T348434 Change-Id: Idf58bd1eb370feff25cfd7aa432572015e7e0edf
When test environments share the same basepython and requirements, might want to optimize the build by having the environment directory shared between the test environments. That was however never officially supported by tox v3: tox-dev/tox#425 (comment) and tox v4 explicitly breaks that assumption by comparing the environemtn based on the name of the test env (which prevents them from being shared): tox-dev/tox#2788 There is a plugin to filter out the test environment `name` from the configuration when doing the comparison: https://github.com/masenf/tox-ignore-env-name-mismatch But I don't want to require that plugin to run tox. As part of the switch to tox v4 (6b8a8f072416) I also had to add a hack to allow tox v3 to provision tox v4 which was to set the environment directory to `.pkg` for the special `.tox` environment. That felt like a hack and is potentially fragile. Unless a solution is found in tox v4 (rather than via a plugin), remove the envdir configuration and the now useless tox v3 back compatibility bit. This will cause multiple identical environments to be created initially, they should be quite fast though since they reuse wheels from the cache. Bug: T348434 Change-Id: I77702f5c220deff0586424aee0d08e719ad6d384
The config option `envdir` is never intended to be used to share env directory [1]. [1] tox-dev/tox#2788 (comment).
The `envdir` is not supposed to be used that way, and it's broken "feature" (technically a bug) in tox >= 4. [1] [1] tox-dev/tox#2788 (comment)
* Remove `envdir` from `tox.ini`. The config option `envdir` is never intended to be used to share env directory [1]. [1] tox-dev/tox#2788 (comment). * Update author name. * Update the description for the cli: `prometheus-hardware-exporter` * Update existing readme and create readme for snap. * Update description of `snapcraft.yaml`. * Move the "grade" in `snapcraft.yaml` back to devel. * Fix broken snap build: move confinement back to `strict`.
The `envdir` is not supposed to be used that way, and it's broken "feature" (technically a bug) in tox >= 4. [1] [1] tox-dev/tox#2788 (comment)
The `envdir` is not supposed to be used that way, and it's broken "feature" (technically a bug) in tox >= 4. [1] [1] tox-dev/tox#2788 (comment)
The `envdir` is not supposed to be used that way, and it's broken "feature" (technically a bug) in tox >= 4. [1] [1] tox-dev/tox#2788 (comment)
The `envdir` is not supposed to be used that way, and it's broken "feature" (technically a bug) in tox >= 4. [1] [1] tox-dev/tox#2788 (comment)
* chore: remove `envdir` from `tox.ini` The `envdir` is not supposed to be used that way, and it's broken "feature" (technically a bug) in tox >= 4. [1] [1] tox-dev/tox#2788 (comment) * refactor: remove multiple relation check in charm code. The `metadata.yaml` support `limit` for interface, this can limits how many relation the interface can be connected to, and we can handle the relation checks in juju level.
Issue
In tox <4 it was possible to re-use the same python virtual environment across envs by specifying a shared
envdir
. Tox 4 however re-creates the virtual environment if the env name is different to the env name that was used to create the virtual environment.It seems that tox 4 remembers the env name used to create the virtual environment in
.tox-info.json
and then decides to re-create the virtual environment if the env name changed.I was not able to spot this change documented under https://tox.wiki/en/latest/faq.html#breaking-changes-in-tox-4. Also, I was not able to find an alternative way to re-use virtual environments across envs in tox 4.
Use case
A common use case for me is to run pytest and pylint with the same set of dependencies. Re-using the same virtual environment avoids the expensive creation of the multiple copies of the same virtual environment. Since dependencies change frequently this cost is significant. In practice, I also run more tools than just pytest and pylint via tox.
Also, I often run the entire test suite locally. For this I run
tox
which runs all envs in theenvlist
. If the virtual environment is re-created between every command I spend a lot of time waiting for the exact same packages to be installed.Environment
Example
Here an example that demonsrates the behavior of tox 3 and tox 4 on the same
tox.ini
.tox.ini
:The
main.py
under test:Bash script demonstrating above described behavior that tox 4 does not re-use venvs where tox 3 does.
Output of the script:
We see that in tox 3, execution of
tox -e pytest
aftertox -e pytest
leads to the virtual environment being re-used.With tox 4, the virtual environment is only re-used if the same env is used, e.g. executing
tox -e pytest
aftertox -e pytest
. Executingtox -e pylint
aftertox -e pytest
leads to tox 4 recreating the virtual environment which tox 4 tells us viapylint: recreate env because env type changed from {'name': 'pytest', 'type': 'VirtualEnvRunner'} to {'name': 'pylint', 'type': 'VirtualEnvRunner'}
The text was updated successfully, but these errors were encountered: