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

Deprecate .egg in the importlib-metadata backend #11996

Merged
merged 1 commit into from
Jun 26, 2023

Conversation

uranusjr
Copy link
Member

This provides us a path to remove all pkg_resources usages on Python 3.11 or later, and thus avoid the problem that pkg_resources uses Python API deprecated in 3.12.

Note that the deprecation is fast-tracked since 3.12 is… soon. This is not exactly fast enough, since the schedule of the pip 23.3 release is a month after CPython 3.12.0. But maybe there’s a way to make it work…?

This provides us a path to remove all pkg_resources usages on Python
3.11 or later, and thus avoid the problem that pkg_resources uses
Python API deprecated in 3.12.
@pfmoore
Copy link
Member

pfmoore commented Apr 24, 2023

Just to note here as well, this will need to go into 23.2. It's not a bugfix so it's missed the boat for a 23.1 patch, sorry.

@pfmoore pfmoore changed the title Deprecate .egg in the imporlib-metadata backend Deprecate .egg in the importlib-metadata backend Apr 26, 2023
@uranusjr uranusjr added this to the 23.2 milestone Apr 26, 2023
@uranusjr
Copy link
Member Author

With #11997 merged and solving the immediate blocker for Python 3.12, should we still aim to fast-track remove egg support in the new backend in 23.3? A part of me wants to but technically there’s no concrete to do that instead of following the normal deprecation cycle instead.

@pradyunsg
Copy link
Member

Let's do a normal deprecation cycle. Alternatively, we could drop this in 23.2 for 3.12+ and 24.0 for 3.11, within the beta period if we really really want to be eager about this.

@pfmoore
Copy link
Member

pfmoore commented Apr 26, 2023

Do we know (or can we find out) what setuptools' plans are? Presumably they don't plan on dropping pkg_resources in the near term, but can we get any indication of how much warning we'll get when that does happen? I'm personally inclined to expedite our removal, just to avoid getting messed around again by this whole situation.

On the other hand, in the past I think we've had good results from our deprecation warnings, so maybe it's worth a full deprecation cycle to get a good feel for the impact.

@pradyunsg
Copy link
Member

Do we know (or can we find out) what setuptools' plans are? Presumably they don't plan on dropping pkg_resources in the near term, but can we get any indication of how much warning we'll get when that does happen?

Well, we can ask -- @pypa/setuptools-team any opinions?

@pradyunsg
Copy link
Member

@pfmoore
Copy link
Member

pfmoore commented Jun 19, 2023

Agreed, let's just do this.

@jaraco
Copy link
Member

jaraco commented Jun 25, 2023

If there are known large-scale blockers to removing pkg_resources, I'd avoid removing it, as it would need to be backed out anyway. I don't have a good place yet to track such large-scale blockers, but I'm not surprised they might exist. I'm all in favor of changes that reduce the impedance to removing pkg_resources. I don't yet know if or when it will be feasible to remove pkg_resources from setuptools. I realize that's vague and largely unhelpful, but that's all the context I have.

@uranusjr uranusjr merged commit 9f72cd0 into pypa:main Jun 26, 2023
@uranusjr uranusjr deleted the deprecate-egg-importlib-metadata branch June 26, 2023 07:01
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants