-
-
Notifications
You must be signed in to change notification settings - Fork 531
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
tox 4 breaks generative env def with -pyXXX fragments if basepython is defined #2838
Comments
I think this is expected behaviour. You need to set [tox]
ignore_base_python_conflict = true
[testenv]
base_python = python3
[testenv:functional{,-py38,-py39,-py310}]
[testenv:other] However, when this is set I see the following:
That seems wrong. I wonder if I introduced a bug? fwiw,
EDIT: And if I drop [testenv]
[testenv:functional{,-py38,-py39,-py310}]
[testenv:other]
|
Yes, non generative targets works. Somehow during the generative target having a python version triggers the conflict with the basepython = python3 |
I believe in tox 2.38 I did not need |
Applying the following diff: diff --git src/tox/tox_env/python/api.py src/tox/tox_env/python/api.py
index 9aa1f839..83d0bb3e 100644
--- src/tox/tox_env/python/api.py
+++ src/tox/tox_env/python/api.py
@@ -145,6 +146,8 @@ class Python(ToxEnv, ABC):
def _validate_base_python(env_name: str, base_pythons: list[str], ignore_base_python_conflict: bool) -> list[str]:
elements = {env_name} # match with full env-name
elements.update(env_name.split("-")) # and also any factor
+ print(f'got env_name: {env_name}')
+ print(f'got base_pythons: {base_pythons}')
for candidate in elements:
spec_name = PythonSpec.from_string_spec(candidate)
if spec_name.implementation and spec_name.implementation.lower() not in INTERPRETER_SHORT_NAMES:
@@ -234,8 +237,10 @@ class Python(ToxEnv, ABC):
base_pythons: list[str] = self.conf["base_python"]
if self._base_python_searched is False:
+ print(f'searching for: {base_pythons}...')
self._base_python_searched = True
self._base_python = self._get_python(base_pythons)
+ print(f'found: {self._base_python}')
if self._base_python is not None and self.journal:
value = self._get_env_journal_python()
self.journal["python"] = value With
Without
So our logic in tox/src/tox/tox_env/python/api.py Line 161 in fd25b2b
Clearly |
Consider the following 'tox.ini' file: [tox] ignore_base_python_conflict = true [testenv] base_python = python3 commands = ... [testenv:functional{,-py38,-py39,-py310}] commands = ... There is a conflict between the base_python value specified in '[testenv] base_python' and the value implied by the 'pyXY' factors in the 'functional-pyXY' test envs. The 'Python._validate_base_python' function is supposed to resolve this for us and either (a) raise an error if '[tox] ignore_base_python_conflict' is set to 'false' (default) or (b) ignore the value of '[testenv] base_python' in favour of the value implied by the 'pyXY' factor for the given test env if '[tox] ignore_base_python_conflict' is set to 'true'. There's a bug though. Rather than returning the 'pyXY' factor, we were returning the entire test env name ('functional-pyXY'). There is no Python version corresponding to e.g. 'functional-py39' so this (correctly) fails. We can correct the issue by only returning the factor that modified the base_python value, i.e. the 'pyXY' factor. To ensure we do this, we need some additional logic. It turns out this logic is already present in another helper method on the 'Python' class, 'extract_base_python', so we also take the opportunity to de-duplicate and reuse some logic. Note that this change breaks the ability of users to use a testenv name like 'py38-64' (to get the 64 bit version of a Python 3.8 interpreter). Continuing to support this would require much larger change since we'd no longer be able to strictly delimit factors by hyphens (in this case, the entirety of 'py38-64' becomes a factor). Also note that this change emphasises issue tox-dev#2657, as this will now be raised for a factor like 'py38-64' since 'tox' (or rather, virtualenv) is falsely identifying '64' as a valid Python interpreter identifier. We will fix this separately so the offending test are skipped for now. Signed-off-by: Stephen Finucane <[email protected]> Fixes: tox-dev#2838
Consider the following 'tox.ini' file: [tox] ignore_base_python_conflict = true [testenv] base_python = python3 commands = ... [testenv:functional{,-py38,-py39,-py310}] commands = ... There is a conflict between the base_python value specified in '[testenv] base_python' and the value implied by the 'pyXY' factors in the 'functional-pyXY' test envs. The 'Python._validate_base_python' function is supposed to resolve this for us and either (a) raise an error if '[tox] ignore_base_python_conflict' is set to 'false' (default) or (b) ignore the value of '[testenv] base_python' in favour of the value implied by the 'pyXY' factor for the given test env if '[tox] ignore_base_python_conflict' is set to 'true'. There's a bug though. Rather than returning the 'pyXY' factor, we were returning the entire test env name ('functional-pyXY'). There is no Python version corresponding to e.g. 'functional-py39' so this (correctly) fails. We can correct the issue by only returning the factor that modified the base_python value, i.e. the 'pyXY' factor. To ensure we do this, we need some additional logic. It turns out this logic is already present in another helper method on the 'Python' class, 'extract_base_python', so we also take the opportunity to de-duplicate and reuse some logic. Note that this change breaks the ability of users to use a testenv name like 'py38-64' (to get the 64 bit version of a Python 3.8 interpreter). Continuing to support this would require much larger change since we'd no longer be able to strictly delimit factors by hyphens (in this case, the entirety of 'py38-64' becomes a factor). Also note that this change emphasises issue tox-dev#2657, as this will now be raised for a factor like 'py38-64' since 'tox' (or rather, virtualenv) is falsely identifying '64' as a valid Python interpreter identifier. We will fix this separately so the offending test are skipped for now. Signed-off-by: Stephen Finucane <[email protected]> Fixes: tox-dev#2838
Impressive that you're using that new version, considering our latest release is
Just because it happened to work with
I'd consider this a bug; it should always fail.
I'd recommend not using that flag and instead fixing your configuration file; I'm marking it deprecated and will remove it at some point in the not too far future. |
@gaborbernat That reads kind of snarky. @gibizer clearly meant 4.2.6. I'll just helpfully point to our own Code of Conduct and emphasise:
(emphasis mine)
Unfortunately Hyrum's Law is a thing, and it becomes doubly important when you have large communities relying on this behaviour. When I added At the very least, the upgrade doc should note this, no?
Please re-consider this. This is a really desirable feature for de-duplicating tox configuration files, especially when multiple |
People seem to be abusing it to create configurations that are confusing, so I'm really not a fan of it. It's not about the bugs, it's about being recommended as a quick fix for fixing confusing configurations.
I'd prefer if we come up with another way to solve this problem.
There's a reason we released this a 4.0 and not 3.x. Not just because is a full rewrite, but also because we intend to not support everything 3 happened to support.
Hence, why I'll not remove this option just today. But I'm also not going to leave it for long. People should find different solutions to this problem, and use this as a stop gap for a few months at most.
Yes, most definitely! |
It seems pretty simply: factor version >
By all means, please suggest one. If it works and we can implement it before we deprecate this feature then I've no issues switching. I'm not aware of any plans to remove this yet though.
Python 3 isn't that long ago. We can't be forgetting the lessons of that transition so quickly. I realise some things are not going to be undone retrospectively but I really don't think we should be piling on the misery by e.g. removing a setting like this. As a general aside, all of our lives (especially yours, I imagine 😄) would have been so much easier if this tox 4 transition had been a gradual, iterative process, like what the SQLAlchemy folks are doing with the 1.4 release before 2.0. The ship has sailed but this is proving really painful.
See above ☝️
|
Can you fill in a feature request issue and explain the problem you're trying to solve in detail? Thanks!
With a full revwrite is hard to do this. I've been sitting on version 4.0 for over a year now, and many people have been commenting to just release it otherwise will never be released 🤷 you'll only find out what unexpected features your users are using once you force them to use the new version. I've had 3 calls to verify before RC before releasing but not many people did, and clearly no one using this unexpected feature. |
My CI test env was broken with the issue while update tox from 4.2.4 to 4.2.5 (not while upgrade from 3.x to 4.x). Line with tox version in test yaml (in later commits I removed base python line from tox config and update version to 4.2.6). Action with issue log: https://github.com/ydb-platform/ydb-python-sdk/actions/runs/3881058691/jobs/6619662667 |
@gaborbernat @stephenfin thanks for pincking this up. I'm happy that this is progressing. |
Sure, see #2846.
That's fair and I sympathise. This being the case though, perhaps as these bugs are identified it would be better to fix the and then consider deprecating the problematic behaviour rather than saying "tough luck, we broke it by accident but won't fix it". Especially when people (like me) are showing up and offering to fix said bugs, rather than asking you to do it for them. |
Consider the following 'tox.ini' file: [tox] ignore_base_python_conflict = true [testenv] base_python = python3 commands = ... [testenv:functional{,-py38,-py39,-py310}] commands = ... There is a conflict between the base_python value specified in '[testenv] base_python' and the value implied by the 'pyXY' factors in the 'functional-pyXY' test envs. The 'Python._validate_base_python' function is supposed to resolve this for us and either (a) raise an error if '[tox] ignore_base_python_conflict' is set to 'false' (default) or (b) ignore the value of '[testenv] base_python' in favour of the value implied by the 'pyXY' factor for the given test env if '[tox] ignore_base_python_conflict' is set to 'true'. There's a bug though. Rather than returning the 'pyXY' factor, we were returning the entire test env name ('functional-pyXY'). There is no Python version corresponding to e.g. 'functional-py39' so this (correctly) fails. We can correct the issue by only returning the factor that modified the base_python value, i.e. the 'pyXY' factor. To ensure we do this, we need some additional logic. It turns out this logic is already present in another helper method on the 'Python' class, 'extract_base_python', so we also take the opportunity to de-duplicate and reuse some logic. Note that this change breaks the ability of users to use a testenv name like 'py38-64' (to get the 64 bit version of a Python 3.8 interpreter). Continuing to support this would require much larger change since we'd no longer be able to strictly delimit factors by hyphens (in this case, the entirety of 'py38-64' becomes a factor). Also note that this change emphasises issue tox-dev#2657, as this will now be raised for a factor like 'py38-64' since 'tox' (or rather, virtualenv) is falsely identifying '64' as a valid Python interpreter identifier. We will fix this separately so the offending test are skipped for now. Signed-off-by: Stephen Finucane <[email protected]> Fixes: tox-dev#2838
* Update magnum-ui from branch 'master' to 452ca7da23f4489bc0dd25cfd031d4f1db04dfa6 - Fix tox tox4 errors if basepython and python in other envs are different. [1] Bumped tox minversion as allowlist_externals is only supported in 3.18 [2] [1] tox-dev/tox#2838 [2] tox-dev/tox#2730 Change-Id: I9d24395a7cc5d8423a58ec1e3ed8468ca6984e77
tox4 errors if basepython and python in other envs are different. [1] Bumped tox minversion as allowlist_externals is only supported in 3.18 [2] [1] tox-dev/tox#2838 [2] tox-dev/tox#2730 Change-Id: I9d24395a7cc5d8423a58ec1e3ed8468ca6984e77
Issue
This tox.ini is worked before in tox 3.28.0 to use the default python3 binary for
other
env while use the specific python binary for thefunctional
envs. With tox 4.6.2. this result in conflict.Environment
Provide at least:
pip list
of the host Python wheretox
is installed:Output of running tox
Provide the output of
tox -rvv
:Minimal example
If possible, provide a minimal reproducer for the issue:
The text was updated successfully, but these errors were encountered: