GitLab

Starting from setuptools 19.4, more concrete from the following commit:

https://github.com/pypa/setuptools/commit/ebc54982

setuptools sorts namespaced packages .path to be in sync with sys.path . That however breaks for wendelin.core used from in-tree or installed in development mode, because we are doing tricks in top-level import redirector (see e870781d "Top-level in-tree import redirector"):

(z+numpy.v2)kirr@teco:~/tmp/trashme/wendelin.core$ python -c 'import wendelin'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "wendelin.py", line 39, in <module>
    __import__('pkg_resources').declare_namespace(__name__)
  File "/home/kirr/src/wendelin/venv/z+numpy.v2/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2081, in declare_namespace
    _handle_ns(packageName, path_item)
  File "/home/kirr/src/wendelin/venv/z+numpy.v2/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2026, in _handle_ns
    _rebuild_mod_path(path, packageName, module)
  File "/home/kirr/src/wendelin/venv/z+numpy.v2/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2050, in _rebuild_mod_path
    orig_path.sort(key=position_in_sys_path)
  File "/home/kirr/src/wendelin/venv/z+numpy.v2/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2045, in position_in_sys_path
    return sys_path.index(_normalize_cached(os.sep.join(parts)))
ValueError: '/home/kirr/tmp/trashme' is not in list

Here wendelin.py added /home/kirr/tmp/trashme/wendelin.core to .path and setuptools' _handle_ns() wants to order that dir's parent in correspondence with sys.path, but parent path is not there - oops.

We can workaround the problem, by first not initializing .path and letting

__import__('pkg_resources').declare_namespace(__name__)

fully handle and initialize it, and only after it is done we make the correction for wendelin modules located not under .../wendelin.core/wendelin/ but under .../wendelin.core/ .

Importing was tested to work with the fix with both setuptools 20.6.7 and older setuptools 17.1.1, i.e. here we should not be breaking backward compatibility.

/reported-by @tatuya, @Camata, @Tyagov