You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are you using pkgutil.extend_path instead of setuptools style namespace packages or in some other way?
The good news is that modulegraph2 (a rewrite of modulegraph using modern python 3 APIs) does support pkgutil.extend_path.
The bad news is that automatically detecting the use of this API is close to impossible using the modulegraph code base, and I'll therefore probably will never fix this issue here.
Original comment by Michael Root (Bitbucket: mike1158, GitHub: mike1158).
Hi, I'd forgotten all about this! We use a common namespace for all our in-house code, but we also have several sub-packages that each get versioned independently. Each of those sub-packages is in a separate path, so we put this in the init.py at the top level of those packages to allow them all to share that common namespace:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
Our use case for modulegraph was to try and find seldom-used packages so that we can factor them out, or to identify what might be using an API that is about to undergo some breaking change.
Original report by Michael Root (Bitbucket: mike1158, GitHub: mike1158).
We use pkgutil.extend_path() frequently to allow multiple module packages in use at our company to all share a common top-level company namespace.
modulegraph.find_modules only considers the first package in the namespace.
The text was updated successfully, but these errors were encountered: