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

imp is deprecated #479

Open
ghost opened this issue Jan 6, 2016 · 8 comments

Comments

@ghost
Copy link

commented Jan 6, 2016

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


According to the docs, imp is deprecated since Python 3.4. Yet pkg_resources relies on it. In particular, it relies on the acquire_lock and release_lock functions, which don't have an equivalent in importlib.

The docs do say, "Changed in version 3.3: The locking scheme has changed to per-module locks for the most part. A global import lock is kept for some critical tasks, such as initializing the per-module locks."

What does that mean for the usage in pkg_resources? Is it possible to eliminate the usage of locks on Python 3.3+ in declare_namespace and fixup_namespace_packages?

This issue was revealed in Pull Request 129, but the resolution was to keep it and the deprecation warnings. What's the proper solution here?


@ghost ghost added major bug labels Mar 29, 2016

@mgedmin

This comment has been minimized.

Copy link

commented Sep 16, 2016

pkg_resources isn't the only place that imports imp

pkg_resources/__init__.py:    import imp as _imp
setuptools/command/build_ext.py:import imp
setuptools/command/install_lib.py:import imp
setuptools/depends.py:import imp
setuptools/depends.py:from imp import PKG_DIRECTORY, PY_COMPILED, PY_SOURCE, PY_FROZEN
setuptools/site-patch.py:                import imp  # Avoid import loop in Python >= 3.3

Python 3.6 upgrades the PendingDeprecationWarning to a full DeprecationWarning, which in practical terms means nothing, only some psychological pressure not to forget about this issue. ;)

@jaraco jaraco referenced this issue May 11, 2017
@5j9

This comment has been minimized.

Copy link

commented Aug 30, 2017

Is it acceptable to temporarily suppress the warnings in setuptools using warnings.catch_warnings or does it need to be a thread-safe or some other solution?

@jaraco

This comment has been minimized.

Copy link
Member

commented Aug 30, 2017

I'm not sure what you're asking. Are you asking if you can suppress the warnings in your code? Well, sure. If you're asking about suppressing the warnings in setuptools, it feels like that might just kick the can down the road. And besides, most applications have these warnings disabled by default anyway, so if a user is enabling them, I would expect them to want to see them.

@5j9

This comment has been minimized.

Copy link

commented Aug 30, 2017

I enable these warnings in my own code to fix issues before they become breaking changes. But when the number of them grows, it becomes hard to keep an eye on them and detecting the new ones become harder. That's why I thought about suppressing some of those that are already reported and known to be rather harmless for the time being...

I'm not sure if this whole thing is a good idea or not, and if it is, whether it is better to be done through the upstream libraries (setuptools in this case) or downstream.

Anyway, I can see why setuptools owners might be reluctant to suppress this warning. I'll find another way.

Thanks for the reply.

@giampaolo

This comment has been minimized.

Copy link

commented Oct 6, 2017

Right now I use this hack in psutil in order to avoid this (and others) deprecation warnings issued by setuptools, which is annoying:
https://github.com/giampaolo/psutil/blob/master/setup.py#L17-L24

with warnings.catch_warnings():
    warnings.simplefilter("ignore")
    try:
        import setuptools
        from setuptools import setup, Extension
    except ImportError:
        setuptools = None
        from distutils.core import setup, Extension
@hugovk

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2018

Setuptools now only supports non-EOL Python versions: 2.7 and 3.4+.

Can imp now be replaced in Setuptools?

@jaraco

This comment has been minimized.

Copy link
Member

commented Aug 11, 2018

@hugovk: You're welcome to give it a try. Perhaps the project should try simply removing the locks and hope that nothing breaks. Please feel free to investigate.

@asottile

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

I started work on the easier parts of this in #1798 -- would appreciate a review :)

jaraco added a commit to jaraco/jaraco.packaging that referenced this issue Jul 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.