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
Open

imp is deprecated #479

ghost opened this issue Jan 6, 2016 · 8 comments

Comments

@ghost
Copy link

@ghost ghost 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
Copy link
Contributor

@mgedmin mgedmin 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. ;)

Loading

@jaraco jaraco mentioned this issue May 11, 2017
@5j9
Copy link

@5j9 5j9 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?

Loading

@jaraco
Copy link
Member

@jaraco jaraco 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.

Loading

@5j9
Copy link

@5j9 5j9 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.

Loading

@giampaolo
Copy link
Contributor

@giampaolo giampaolo 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

Loading

@hugovk
Copy link
Contributor

@hugovk hugovk commented Aug 9, 2018

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

Can imp now be replaced in Setuptools?

Loading

@jaraco
Copy link
Member

@jaraco jaraco 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.

Loading

@asottile
Copy link
Contributor

@asottile asottile commented Jul 11, 2019

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants