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.