TestNamespaces.test_namespace_package_importable failed with 31.0.0 #884
Comments
|
Bummer. I'd ask you to help debug, but these tests are particularly difficult to debug. I'll try to find a way to make the test failures more informative. |
|
Probably related #885 |
|
I'm afraid I'm unable to replicate this failure. I thought maybe Arch was implicated because the tests are passing on Ubuntu, but now I've run the tests on Arch Linux and they also pass: What does one have to do to replicate the failure you've seen? |
|
Sorry for the late response. I am using |
|
I'm able to replicate the issue as long as I have an old setuptools (<=31.0.0) installed in the environment. However, if I upgrade my python environment setuptools to 31.0.1, the issue goes away: The issue seems to be that when that test runs, it is somehow picking up the system-installed setuptools and not the version under test. That doesn't happen in the canonical tests because they're run under tox now, which installs setuptools rather than |
|
Actually, now I notice that my failure is different from yours, but still I suspect the failing test is dependent on which setuptools is installed. |
|
Indeed, if I downgrade to |
|
I also got your errors now, but the errors in the OP still persist. I have tried to install the latest setuptools to system and confirmed that fixes the problem. |
|
So I've devised a workaround, pushed to the issue-884 branch. I'm trying to decide if setuptools should support running tests in this model (with pytest-runner) or if the added complication to the test code plus other issues that might arise down the road suggest that this should be an unsupported test runner, and that tests should always be run using tox or with the current setuptools installed into the environment. Perhaps you have an opinion on the matter? What leads you to use pytest-runner over tox? Would a suitable workaround be to 'setup.py develop' setuptools before running 'ptr'? One of the reasons I've been moving away from pytest-runner is exactly this one, where subprocesses don't get the "package" environment (mainly sys.path) of the parent process without the tests being aware of this contingency. If pytest-runner were the recommended test runner for setuptools, it would certainly be the case that setuptools' test suite should support this mode, but since tox is the recommended runner, I'm inclined not to support the nuances of pytest-runner. I'm open to being convinced if you feel strongly about it. |
|
The main reason is that generally we don't allow network access during the whole build/test process when packaging for a distro. I have tried |
|
Hrm, the |
|
I see. Yes, that is a meaningful test case which seems reasonable to support. I think I've found how to make it work. As part of your bootstrapping logic, grab the test dependencies: Then when offline, invoke the tests thus: That worked for me here on macOS. Will that technique also work for your use case? |
|
Since we do not have a network-ready bootstrap process (which brings in nondeterminacy and not good for reproducible builds), I can only manually list all wheels down in the dependency tree as sources and update them for each version. |
|
I'm leaning now toward this being a pytest-runner bug - that pytest-runner should set PYTHONPATH to include the eggs added to sys.path. Oh, I see in pytest-dev/pytest-runner#20, that was done, but it doesn't include the current working directory. Then, as I delve into the test command, I see that it already has support for adding the project itself to sys.path. So maybe the issue is more straightforward. Maybe the tests are failing because they're setting PYTHONPATH rather than extending it. |
|
I had a breakthrough! Turns out all of the behavior that was needed was already coded in the |
|
That's awesome! Thanks a lot for the additional effort :D |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Python 3.5.2
pip 9.0.1
Arch Linux x86_64 latest.
The following new test failure was introduced in 31.0.0:
The text was updated successfully, but these errors were encountered: