-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
zope.configuration failure to find dependency #912
Comments
Thanks for the report and the reference to a previous issue. It's possible it's related to #900. I think I'm going to need more to go on, though. When I try to replicate your issue by installing the packages and using PYTHONPATH, they work fine:
Same with virtualenv:
So there's some other factor involved that's triggering your error. Can you help track the issue by describing the steps you have to take to encounter it, and preferably distill those steps to their most essential? |
I simply ran |
This has something to do with namespace packages, see this comment: zopefoundation/zope.configuration#16 (comment) I cannot explain why mixing an old-style explicit namespace package with a PEP-420 implicit namespace package works on Python 3.4, but fails on 3.5 and 3.6. I've just double-checked that I have the latest versions of virtualenv, pip and setuptools installed. |
Well, the issue just doesn't happen to me:
Has the issue been fixed? |
Even
|
I get a similar result if I use virtualenv instead of pyvenv. |
No, there have been no changes on As mgedmin pointed out it seems to happen reproducibly if you install the package non in dev-mode before running the test suite The consequence is that py2 after
py3.6:
py3.6 after
|
I used this small script
to run a git bisect
So it seems to indeed be the same as #870 originally caused by the fix for #805 |
@jaraco: I've committed a workaround to zope.configuration's |
Unfortunately, if you read the final comment in #870, it indicates that the change that caused #870 was backed out in v31, so that doesn't really help.
That's good, and begs the question - should this workaround be the recommended fix? It is the technique I've adopted for my namespace packages as a matter of course (and because it's confusing to me when running tests to have two copies of the package, one in source and one installed). Let's assume for a moment that we desire to continue to support this model (pip installing the package under test, then running setup.py test on it). What is causing the failure? That's what I'll investigate now. |
The issue is almost certainly instigated by the code that manipulates the sys.path and working set for the project under test. If I create a simple environment and even add
One would expect this because
In Setuptools 31, we added support for develop-installed packages to also install one of these But even with The question that remains - should the |
I spent some time tracing the behavior and I was able to replicate the error prior to the tests starting. For posterity, here's what I found:
|
I've found I can also replicate the error thus:
Here, it seems the import of pkg_resources is somehow interfering with the way Python imports namespace packages, and there's probably something pkg_resources can do. |
Revisiting my latest finding above, I don't think that demonstration has any value at all because it's not somehow incorporating the zope.interface egg. Incorporating that egg on sys.path, it does appear to work just fine.
|
So once again I'm stuck not fully understanding what it is about the test runner that's breaking the import... I may be able to investigate more later but for now I'm stuck. |
FWIW, I just ran into this problem with lazr.config: http://lists.idyll.org/pipermail/testing-in-python/2017-February/007001.html I solved it differently in my case. I stopped using It's very perplexing! |
Yes, It's also frustrating for Gentoo packaging. We already had to implement one workaround for namespaces in the past, and now it turns out we need a second one. |
Possibly related. Some time after we also had an issue with @warsaw maybe that's a fix for your issue? |
So I encountered this too and my impression as to why this is failing is that it's because the namespace package's |
In Nixpkgs we recently changed the way we install |
While trying to upgrade zope.configuration for Nixos, I found this problem, which sounds similar to:
#870
I tried already with Setuptools 32.3.1, but the result is the same. This is not Nix specific, but happens also in a normal Python3.6 virtualenv
The text was updated successfully, but these errors were encountered: