Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Difference in sys.path order, depending on how run #686
In the coverage.py test suite, I have tests that check various environmental values to see that they are they same for
I'm guessing this has something to do with #674, but I don't understand why.
The actual diff of sys.path for the two environments is:
Is this expected? Is there something I can do to get the identical behavior in the two environments?
Hi Ned. I am slightly surprised by the behavior too, and I think you're right that #674 is implicated. To confirm, just set SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite, and if the tests pass again, we'll know for sure that the change is implicated.
Assuming that's the case, here's what I think is happening:
I have a few questions - is setuptools being upgraded as part of the process? If you ran the coverage tests again at the end, I would expect sys.path to be the same as the second run; is it?
It occurs to me that a more proper workaround, assuming you have Setuptools >= 12 installed from the beginning, is that if you were to set SETUPTOOLS_SYS_PATH_TECHINQUE=raw, it would give forward compatibility and should give consistent results.
I hope that helps. Let me know what you find.
@jaraco running the failing test with
In this case, the test runs python and coverage directly, one after the other within one test, so I'm not sure there's an opportunity for things to change between them. It seems like something is different about running a program with "python" and running it with a setuptools-created command like "coverage".
To run one test:
I can try other experiments if you direct me :)
Oh, my. I wouldn't have expected it, but the
@minrk: Can you investigate and see if you can identify a way for pkg_resources to honor the ordering implied by
@jaraco I've found the culprit, but I'm not 100% sure what the desired behavior is.
The triggering sequence:
It seems to me that
Simply removing the
The high-level problem seems to be that
For my usage, 1. seems to be the problem - I never want pkg_resources to touch sys.path under any circumstances.
I also don't fully understand why pkg_resources is modifying sys.path, because
I assume there are some exceptional cases where pkg_resources is actually meant to modify sys.path. Can you enumerate those, so we can limit the condition when sys.path is modified to less than always?