
Description
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 the setup_requires
package in question has a namespace package. For example:
#!python
setup_requires = ['foo.bar > 1.1']
where foo
is a namespace package. The fix ensures that the path to the newer version of foo.bar
is added earlier on foo.__path__
while still maintaining the original foo.__path__
entries in their original relative order.
Unfortunately this fix breaks the (likely more common case) where there are two copies of foo.bar
on sys.path
to begin with. For example, if upon starting the interpreter it has the entries:
#!python
sys.path = [
...
'path/to/virtualenv/site-packages/foo.bar-1.1.egg/'
...
'system/site-packages/foo.bar-1.0.egg/'
]
when one performs import foo
, the first entry is found first resulting in
#!python
foo.__path__ == [ 'path/to/virtualenv/site-packages/foo.bar-1.1.egg/']
which is fine. But then as declare_namespace
continues its march it gets to the later path entry which ends up reordering foo.__path__
so that
#!python
foo.__path__ == ['system/site-packages/foo.bar-1.0.egg/', 'path/to/virtualenv/site-packages/foo.bar-1.1.egg/']
Thus a call to import foo.bar
ends up importing the old foo.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 in fixup_namespace_packages
which is where it is actually necessary, and not in _handle_ns
generally.