import pkg_resources.py31compat causes no module error

While pip installing jupyter with a version of setuptools cloned just before this post, I came across a no module error coming from setuptools:

ImportError: No module named py31compat

which comes from setuptools/setuptools/sandbox.py, line 15

import pkg_resources.py31compat

However, in setuptools/pkg_resources/__init__.py, line 72, py31compat is imported there:

from . import py31compat

Therefore, it seems unnecessary to do

import pkg_resources.py31compat

in sandbox.py. It’s a python file already included when importing the pkg_resources submodule. One can just do:

import pkg_resources

This fixed the problem for me.

Any reason for using an import statement directly to the python file within the submodule that already includes it in init.py?

I’ve also had this problem on older python environments while installing other libraries. Not sure what would change in an existing environment to cause this problem.

[gweis]

Seeing a similar issue, but when starting up Zope. (I know Zope does a lot of module path scanning and importing which may cause this.

However, when I replace the line in pkg_resources.__init__.py from . import py31compat with py31compat = __import__('pkg_resources.py31compat') it works without a problem. (but I have no idea what the actual difference is there) even the next line works which should be the equivalent of the relative import. py31compat = __import__('', globals(), locals(), ['py31compat'], 1)

Really no idea what’s happening here and where the actual problem is. Just thought I’ll throw this in to provide a potential pointer into the issue.

[gweis]

Finally tracked it down.

I suspected that pip may be the issue because, that was the only other pkg_resources module I could find in my file system. (also there is no other setupttools version installed anywhere)

However, in my case I have a namespace module org with an __init__.py file containing: __import__('pkg_resources').declare_namespace(__name__)

When my app starts up, something is importing stdlib copy module which tries to import from org.python.core import PyStringMap which will load my __init__.py from my namespace package, which again tries to use copy (within pkg_resources/_vendor/pyparsing) and then somewhere further up in the call stack, something was catching the AttributeError on import and seemed to have left some of the module imports in a funny state. etc…

Essentially, using __import__('pkg_resources').declare_namespace(__name__) created an recursive import chain in my case.

Lesson to take form this. Don’t use org as namespace package or use pkgutil.extend_path instead of pkg_resources.declare_namespace if unavoidable. Not sure whether pkgutil.extend_path would have any side effects or not. The docs are not very specific about the difference of the approaches.

(Still not clear why using __import__ works but from . import doesn’t though.)