Emit less cryptic error message for a missing namespace package declaration

[ghost]

Originally reported by: ncoghlan (Bitbucket: ncoghlan, GitHub: ncoghlan)

---

The error message received when a system installed package is missing a "namespace package" declaration is really cryptic. I encountered this for http://beaker-project.org when our common library was missing the namespace package declaration (it originally didn't seem necessary, since that package is the one that owns that namespace, and does have its __init__.py file installed as part of the OS package)

When running from a source checkout, we don't actually care that the system version is present, because sys.path ensures the installed released version is ignored. This also holds true for bkr.__path__.

However, because of the missing declaration, pkg_resources interprets this as an attempt to import a conflicting version of a top level module and ends up emitting a totally inappropriate error message from check_version_conflict() (see the final warning in
https://bitbucket.org/pypa/setuptools/src/6aa3034bc297e98ed1a8422d96754cc0d6734667/pkg_resources.py?at=default#cl-2545)

There should be something in declare_namespace() that checks for this and emits a less cryptic error message that makes it clear:

1. It found some metadata for that package (and where it found it)
2. The metadata doesn't say anything about this being a namespace package

See http://stackoverflow.com/questions/13915269/why-do-i-get-userwarning-module-dap-was-already-imported-from-none/ for some background

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/2

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

Agreed. Let's tackle this first thing after the 0.7 release.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

I've started looking at this, but I'm unable to replicate the failure. Can you put together a minimal test case the reproduces the environment that surprisingly raises the warning? In particular, it should use setuptools and Python only and shouldn't involve package managers. The instructions should install a minimal package in such a way that working with that package in '.' and importing pkg_resources triggers the warning (at least, if I understand the failure conditions as described above). If I don't understand the failure properly, then describe a similar scenario that triggers the unexpected warning.

I suspect that the suggestion that "there should be something in declare_namespace()" may not be appropriate here because the packages in question are not namespace packages. Thus, I wouldn't expect declare_namespace to be involved.

[ghost]

Original comment by ncoghlan (Bitbucket: ncoghlan, GitHub: ncoghlan):

---

Building the docs on Fedora on a fresh CPython checkout is one current
reproducer, but I'll try to come up with something simpler soon.

General pattern:

1. Have a package that includes a pkg_resources namespace package, but
   doesn't declare it as such in its setup.py metadata.
2. Have a dev copy early on your path, plus a fully installed copy later on
   your path.
3. Import the dev copy, get the warning.

The actual bug in the user code in this situation is most likely the
missing "this is a namespace package" declaration from setup.py, but unless
you already know that, the error message doesn't lead you in the right
direction.

[ghost]

Original comment by samposm (Bitbucket: samposm, GitHub: samposm):

---

This is not minimal in the sense @jaraco asked, but: On an Ubuntu machine:

#!shell

sudo apt-get install python-dap

and then

#!python

python
>>> import pkg_resources
__main__:1: UserWarning: Module dap was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path

[silkentrance]

@pganssle This might have been resolved by PEP420 and #1312.

[pganssle]

Really hard for me to tell without an MWE.

@ncoghlan Should we close this?

[ncoghlan]

I'd say close it - so much has changed with namespace handling since I first filed this that I don't think it's relevant any more, regardless of whether the original misbehaviour has been fixed or not.

[pganssle]

Sounds good. We can re-open or open a new issue if something like this comes up again.