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

python pkg_resources performance issues #7393

Closed
tgbugs opened this issue Apr 17, 2020 · 6 comments
Closed

python pkg_resources performance issues #7393

tgbugs opened this issue Apr 17, 2020 · 6 comments
Labels
inactive Denotes the issue/PR has not seen activity in the last 90 days. python

Comments

@tgbugs
Copy link

tgbugs commented Apr 17, 2020

What version of protobuf and what language are you using?
Version: master
Language: Python
What operating system (Linux, Windows, ...) and version?
Gentoo linux, but the problem is present on all platform.

What runtime / compiler are you using (e.g., python version or gcc version)
Version independent, but, pypy3, python3.6, python3.7.
What did you do?
Steps to reproduce the behavior:

  1. Have many (hundreds of?) python packages present on your system.
  2. In your favourite shell run python
  3. import google.protobuf or even just import google

What did you expect to see
Not waiting 300ms for google or google.protobuf to improt.
What did you see instead?
Waiting 300ms for import to finish because pkg_resources scans all installed packages.

Anything else we should know about your project / environment
This is a result of pypa/setuptools#510.
Suggested fix is to remove all top level imports of pkg_resources. For 3.7 and 3.8 it could be replaced with importlib.resources or importlib.metadata and apparently there are backports as well (see hgrecco/pint#1008 (comment)).
Here is the list of bad import statements.

__import__('pkg_resources').declare_namespace(__name__)

__import__('pkg_resources').declare_namespace(__name__)

__import__('pkg_resources').declare_namespace(__name__)

@haberman
Copy link
Member

haberman commented Feb 2, 2024

Can you send a PR? It's not exactly clear to me what we should change this to.

We currently require Python 3.8 or higher.

Can we just delete our __init__.py files entirely, per PEP 420?

@tgbugs
Copy link
Author

tgbugs commented Feb 4, 2024

Will see if I can dig back in on this and figure out what the current behavior is vs what removing some of the __init__.py files is. I think the main test case is that various import statements continue to work after the change.

@haberman
Copy link
Member

Sounds good. I'm unassigning myself since I'm not working on this myself. But I'd be happy to see a PR.

@haberman haberman removed their assignment Feb 12, 2024
Copy link

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

@github-actions github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label May 13, 2024
Copy link

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 28, 2024
@cwegener
Copy link

I just ran into this legacy namespace problem myself on Ubuntu 22.04 when trying to use python3-protobuf

I don't even understand why namespacing is used in the first place here?

Isn't there just ONE package that is importable anyway? (google.protobuf)

Why would namespacing be needed with just ONE single package? Does anybody know?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inactive Denotes the issue/PR has not seen activity in the last 90 days. python
Projects
None yet
Development

No branches or pull requests

4 participants