-
-
Notifications
You must be signed in to change notification settings - Fork 528
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 2.2.0+ breaks some tox.ini config files due to recursion issue #285
Comments
Original comment by sfermigier Current version is 2.3.1 which fixes the issue, at least to people who have tried it. So I guess the issue can be closed. |
Original comment by @booxter It's two months since the bug was revealed. Isn't it time to fix it either by a new release with a fix or a revert of the offending patch? |
Original comment by @hugovk
The actual tests are failing, but the point is Tox works and actually runs the tests with 2.1.1 and 2.3.0.dev2, whereas 2.2.1 gives Thanks! |
Original comment by romcheg Tested 2.3.0.dev3 with python-fuelclient. Seems to work. |
Original comment by bossylobster https://github.com/google/oauth2client still broken |
Original comment by sfermigier Works for the Abilian project (unlike version 2.2.1). Thanks ! |
Original comment by @maiksensi I also tested 2.3.0.dev3 - works great. Thank you! |
Original comment by @cedk I tested the version 2.3.0.dev3 and it works for the Tryton project. |
Original comment by @hpk42 i think i have fully fixed the issue now, please try it out with:
which should give you |
Original comment by @cedk @hpk42 Don't you think it will be better to apply your plan from https://bitbucket.org/hpk42/tox/issues/285/tox-220-breaks-some-toxini-config-files#comment-23275850 and publish a release that doesn't break the existing configuration files until this issue is fixed? Thanks. |
Original comment by @kozhukalov Issue #288 was marked as a duplicate of this issue. |
Original comment by @nelfin @kozhukalov, this breaks non-env: substitutions in [setenv]. |
Original comment by @kozhukalov This patch fixes the issue
|
Original comment by @stefano-m I am having the same problem with tox 2.2.1 where I reference I have the feeling that one substitution bounces back to the other. PDB tells me that the recursion fails in
where the following is called
Maybe it has something to do with the
method? |
Original comment by @nelfin Actually no regression tests fail in my pull request. It was only the initial changeset that introduced a failure. I'll look to adding another test case for |
Original comment by @hpk42 @nelfin i didn't look at it yet. Will check it out next week -- even if just one regression test fails (like also in my branch) it can hint at a severe regression that will break people's tox.ini file. If i am not mistaken we also need to be lazy wrt to subtitutions like
This means we can not just compute setenv completely up-front. could you mark the tests that fail with your branch |
Original comment by @nelfin @hpk42 have you seen my pull request from a little while ago? https://bitbucket.org/hpk42/tox/pull-requests/176/compute-closure-of-osenviron-and |
Original comment by @hpk42 I just spend 4 hours trying to resolve this issue according to my plan. See https://bitbucket.org/hpk42/tox/branch/issue285#diff for the current work. It fixes all setenv issues but there remains one more ordering-issue which i couldn't quickly resolve. Am running out of time for this week, probably will try on tuesday or wednesday to continue if nobody else can fix the remaining bug (which is a hairy ordering issue if i am not mistaken). I also need to review what i did this morning. Folks, one more thing: my company (http://merlinux.eu) offers support contracts for fixing bugs, implementing features for tox, devpi, pytest: you might consider getting one for your company if you heavily depend on things. Usually we then fix things within two days. We have three companies who signed up and their issues usually take precedence FYI. |
Original comment by @hpk42 Seems we need to work harder for env-substitution. The problem was a side effect from me merging https://bitbucket.org/hpk42/tox/pull-requests/169/tries-to-fix-99/diff trying to fix #99 where i failed to see in the review that env-substitution breaks for setenv itself. Maybe @Itxaka can also take a look. I guess we need to get more lazy about parsing the setenv NAME=VALUE settings and that's not just a few lines of change if i am not mistaken. We probably need to introduce a mode where we don't do env-subsitutions on VALUE so that we can know about all NAMEs in setenv. And in a second pass more intelligently resolve setenv-set variables (noting recursions etc.) Not sure when i get to it. If no fix is done neither by any of you nor by mid next week i'll probably revert the PR that caused the problem (it's valid to want to have #99 resolved of course but on balance it's more important to keep existing configs working). |
Original comment by timmwagener Same issue here. Not sure if I'm allowed to show tox.ini files... |
Original comment by @nelfin I have a partial fix for this here: https://bitbucket.org/nelfin/tox/branches/compare/nelfin/tox:37ee634%0Dhpk42/tox:default#diff but this introduces a regression and I haven't yet fixed self-referencing keys like this:
|
This one flies far over my head. Can anyone who is into this give a bit of feedback about this? |
@obestwalter from memory @hpk42's work on lazy evaluation of setenv substitutions solved 99.9% of people's use cases for this: only mutually recursive setenv clauses weren't fixed, but they never worked previously: def test_setenv_mutual_reference_issue285(self, monkeypatch, newconfig):
"""Prevent setenv variables from producing mutual infinite recursion."""
monkeypatch.delenv('TEST1', raising=False)
monkeypatch.delenv('TEST2', raising=False)
config = newconfig("""
[testenv]
setenv =
TEST1={env:TEST2}
TEST2={env:TEST1}
""")
reader = SectionReader('testenv', config._cfg)
assert reader is not None
with pytest.raises(tox.exception.ConfigError):
reader.getargvlist('setenv') |
Hi @nelfin thanks, but where is that test from? I can't find it in the current incarnation and the changelog refers to this issue as fixed (with your help :)). I just adapted your test to the current version and it passes, which means that a config error is thrown correctly to prevent the recursion. I wonder why that test is not in the code base anymore though. Shall we add this test to document this behaviour? We can't close the bug 99.9% so I would say, we close it 100% and if that specific problem pops up again a new issue needs to be filed. |
I don't know if it ever was in the codebase, that test came from https://bitbucket.org/hpk42/tox/pull-requests/176/compute-closure-of-osenviron-and/diff. I agree with your sentiment and say close this as it appears to be fixed. Specifically, https://github.com/tox-dev/tox/blob/master/tox/config.py#L282 seems to check for setenv cycles. |
Don't bother including that test by the way, looks like it was covered by |
o.k. great let's close this then - thanks for bringing me up to speed! |
tox 2.2.0+ breaks the following projects in OpenStack: http://codesearch.openstack.org/?q=%3D\{env%3A.*%3F%3A.*%3F\}&i=nope&files=tox.ini&repos=
networking-l2gw, networking-vsphere, neutron, neutron-lbaas, and python-fuelclient
The OpenStack bug for the failure is: https://bugs.launchpad.net/neutron/+bug/1515335
The logs of the failure can be found at: http://logs.openstack.org/22/244122/2/gate/gate-neutron-python27/414e071/console.html#_2015-11-11_16_10_42_148
The line in tox.ini that triggers it is: https://github.com/openstack/neutron/blob/master/tox.ini#L26
Copying the section that triggers the issue here just in case:
[testenv:api]
basepython = python2.7
setenv = {[testenv]setenv}
OS_TEST_PATH=./neutron/tests/api
TEMPEST_CONFIG_DIR={env:TEMPEST_CONFIG_DIR:/opt/stack/tempest/etc}
OS_TEST_API_WITH_REST=1
The problematic line is the one setting TEMPEST_CONFIG_DIR.
The text was updated successfully, but these errors were encountered: