-
-
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
Plugins cannot use custom tox.ini config sections with a suffix name shared by a testenv #2926
Comments
Thanks for the report. Now that I'm back from vacation, I'll look into this one. |
The bug potentially exists in these two lines tox/src/tox/config/source/ini.py Lines 43 to 44 in 23ebd04
Regardless of whether the The fix that I have in mind changes the logic here to look up the _section_mapping for the given section's name only when the prefix is I need to further test compatibility concerns, but I think this approach is ideal, beacuse it also allows tox plugins to leverage tox config parsers to read top-level, non-testenv sections that might have names overlapping with PR coming soon. |
regression test for plugin behavior in tox-dev#2926
ensure that loaders returned from .ini source are bound to the correct section prefix, if specified. add comment explaining why the code must look up the name in the _section_mapping fix tox-dev#2926
ensure that loaders returned from .ini source are bound to the correct section prefix, if specified. add comment explaining why the code must look up the name in the _section_mapping fix tox-dev#2926
Issue
I noticed this with recent tox 4.x failing in CI for tox-docker plugin, which preivously worked.
The issue seems to be deep inside the config parsing code, if both a
[testenv:foo]
and[docker:foo]
section exist with the same suffix ("foo"). Somewhere inside the parser code it seems to get confused and is looking for the docker plugin's keys within the testenv config section, and fails.Here's a minimal(ish) script & tox.ini which reproduces it:
tox.ini
tox_bug.py
setup.py
You can reproduce with
python setup.py develop && tox -e foo
:That should pass with, as the plugin is trying to read the
bar = baz
line of config, then assert that it gets a truthy value.Environment
It seems this issue was introduced in 4.0.0rc1:
vs
Provide at least:
The text was updated successfully, but these errors were encountered: