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
#141 introduces regression in importing namespace packages #207
Comments
Original comment by embray (Bitbucket: embray, GitHub: embray): This first change moves some things around in test_easy_install to support a new test "test_setup_requires_override_nspkg" which specifically tests the use case my original changes to |
Original comment by embray (Bitbucket: embray, GitHub: embray): Encountered this lovely issue again for the first time in a while, when the software stack used by many of my coworkers upgraded setuptools for the first time in a long time. The fix to #141 handled namespace packages in such a way that whenever a new distribution is activated, if it contains a member of a namespace package, it inserts that package's path first into the namespace package's However, this is at odds the normal behavior, where the first time some member of a namespace package is imported, I have a potential fix for this that ensures that a namespace package's |
Did 8a304f3 fix this issue? Should it have been closed? |
Presumably so. |
Originally reported by: embray (Bitbucket: embray, GitHub: embray)
Unfortunately the fix to #141 was basically my code :(
The regression is caused by the changes to
pkg_resources._handle_ns
. That change was added to support the scenario reported in #141 where thesetup_requires
package in question has a namespace package. For example:where
foo
is a namespace package. The fix ensures that the path to the newer version offoo.bar
is added earlier onfoo.__path__
while still maintaining the originalfoo.__path__
entries in their original relative order.Unfortunately this fix breaks the (likely more common case) where there are two copies of
foo.bar
onsys.path
to begin with. For example, if upon starting the interpreter it has the entries:when one performs
import foo
, the first entry is found first resulting inwhich is fine. But then as
declare_namespace
continues its march it gets to the later path entry which ends up reorderingfoo.__path__
so thatThus a call to
import foo.bar
ends up importing the oldfoo.bar
later on the path.If that's all confusing, I will attach a regression test in a bit. I think the solution is to handle the
__path__
reordering infixup_namespace_packages
which is where it is actually necessary, and not in_handle_ns
generally.The text was updated successfully, but these errors were encountered: