Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't find packages when pkgutil.extend_path() is used #42

Open
ronaldoussoren opened this issue Aug 18, 2017 · 2 comments
Open

Doesn't find packages when pkgutil.extend_path() is used #42

ronaldoussoren opened this issue Aug 18, 2017 · 2 comments
Labels
bug Something isn't working

Comments

@ronaldoussoren
Copy link
Owner

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.

@ronaldoussoren
Copy link
Owner Author

Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren).


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.

@ronaldoussoren
Copy link
Owner Author

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.

Does that info help at all?

@ronaldoussoren ronaldoussoren added major bug Something isn't working and removed major labels Jan 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant