Release 25.1 (April)

[ichard26]

I'm mostly filing this now as I have some interest in being the next RM. Both to increase the maintainers available to do a release, and to give @sbidoul a break :)

There are several deprecations scheduled for removal in the 25.1 milestone which definitely makes it somewhat precarious, but I'd be happy to at least learn the mechanical parts and have someone else help me through the decision-making. pip 25.3 (October) is likely going to be a busy time for me, so 25.2 would be the best time for me to learn the release flow.

Any objections or thoughts? cc @pypa/pip-committers

[notatallshaw]

I'm in agreement that having different maintainers wear the RM hat is important, both for different maintainers being familiar with the process and making sure the release instructions are correct. Also, I'd be happy to volunteer for a different release later in the year.

[pfmoore]

I'd like to do a release sometime, just to check the new process on Windows. My open source time has been severely limited recently, but I can try to do 25.1 (and if @ichard26 or @notatallshaw want a blow-by-blow account of the process I used, I'm happy to do some form of running commentary or walkthrough).

[ichard26]

Sure, we can do that. It'd be nice to shadow an experienced RM for a release cycle before being a RM. In my original post, I got the release months mixed up. 25.2 (July) is probably the best time for me be the RM (unless I go on vacation then, but I haven't decided yet). I'm still available for 25.1 if availabilities change.

I've assigned the issue to you to mark you as our tentative RM for pip 25.1.

I'm happy to do some form of running commentary or walkthrough

Yes please! The mechanical work is likely probably well-documented (updating get-pip...?) but it's the decision-making and things to look out for I'd appreciate. (Perhaps we could turn your commentary into informal checklists?)

[notatallshaw]

One thing that needs to be decided is whether to drop support for Python 3.8 (#12989).

My main concern is that pip can't vendor urllib 2.x until Python 3.10+, and I don't know the timeline for urllib 1.x support ending, the docs currently say "continue supporting v1.26.x releases with both security and bug fixes for the forseeable future": https://urllib3.readthedocs.io/en/1.26.6/v2-roadmap.html, but 2.x has been out for nearly two years now.

[ichard26]

We can simply ask @sethmlarson. Do you have plans to drop support for urllib3 1.x? Either entirely, or only on Python 3.8 specifically?

[pfmoore]

If we get consensus on #12989 to drop support for Python 3.8, and someone does the work to create the necessary PR, that's fine by me with my RM hat on. It's not related to urllib3 (although maybe getting consensus will be affected by the urllib3 position - I doubt it, but it's possible).

As far as I can see, with regard to urllib3 version 2, we're blocked until we drop support for Python 3.9 - at least that seems to be what this comment suggests. That's not going to be until pip 26.0 at the absolute earliest (Python 3.9 goes EOL just after pip 25.3 will be released).

Regardless, anything related to the urllib3 migration should be discussed on #12857. And I'm going to say that barring something unexpected, it won't be happening in 25.1.

Either entirely, or only on Python 3.8 specifically?

I'm pretty strongly against shipping two vendored copies of urllib3 so that we can pick which one to use based on the Python version. And having different wheels for different Python versions is a big enough change that it would need its own issue to track it (and I'd probably say no to including it in 25.1 anyway).

[ichard26]

I wasn't implying that we'd vendor two copies of urllib3. I was making the distinction since if urllib3 1.x is going to be completely unsupported, then we have a bigger problem that just Python 3.8 support since we aren't a position to properly support an unmaintained HTTP library. If urllib3 1.x is planning to drop Python 3.8 support, then pip can simply move in the same direction and also drop Python 3.8 support.

and someone does the work to create the necessary PR

I had a PR open to drop Python 3.8 support (#13190) , but it got no attention so I gave up and closed it. I don't care strongly enough to push for it.

And I'm going to say that barring something unexpected, it won't be happening in 25.1.

It won't because there is no point. We aren't planning to drop Python 3.9 for a while and before then, upgrading to urllib3 2.x is blocked.

I'm honestly pretty confused here. I don't want us to consider anything BUT potentially dropping support for Python 3.8 this release. That is all, nothing more.

[pfmoore]

I had a PR open to drop Python 3.8 support (#13190) , but it got no attention so I gave up and closed it.

I wasn't a huge fan of the size of the PR. That may be part of the reason you got little interest - 197 files changed is way too much to review. I don't think we normally run pyupgrade like this when we drop support, we just leave the code unchanged and gradually use newer constructs when appropriate. Also, why deliberately break people who want to continue using Python 3.8 (unsupported, of course)? Sorry - I probably could have commented to that effect at the time.

I'm honestly pretty confused here.

Me too. Let's assume urllib3 is irrelevant (for 25.1, at least).

The relevant issue for dropping 3.8 support is #12989, which feels inconclusive to me right now. So we won't be dropping 3.8 in 25.1 unless someone pushes there for consensus. But personally, I don't think supporting 3.8 is causing us any issues, and download numbers (8.3% in December isn't that small) make me inclined to be cautious.

[ichard26]

I don't think we normally run pyupgrade like this when we drop support

We did for Python 3.7. It was much a smaller change, however (see the pyupgrade commit in #11944).

Also, why deliberately break people who want to continue using Python 3.8 (unsupported, of course)?

It's not so much that I'm trying to break people stuck on Python $version, but that if we're doing to make the formal designation that $version is unsupported, we should fully take advantage of the new/improved constructs. The codebase is going to quickly regress without automated testing, regardless. It'd only take one modern typing import in some unrelated change to cause pip to immediately crash on an unsupported Python version.

Now, I'm actually pretty ambivalent about switching the codebase to 3.8+ typing constructs wholesale specifically. I do like the changes, but if we don't want to review it, then meh, I don't care. We'll just need to disable of the pyupgrade rules in Ruff.

---

I'm pretty sure we're talking past each other at this point, so all else I'm going to say is that I don't care if we drop Python 3.8 this release or not. I won't be picking up that task, and frankly, pip is foundational enough where it'd be nice to maintain official support when it's not a burden (and it isn't).

[pfmoore]

It was much a smaller change, however

That's probably why I missed it 🙂

I'm pretty sure we're talking past each other at this point, so all else I'm going to say is that I don't care if we drop Python 3.8 this release or not. I won't be picking up that task, and frankly, pip is foundational enough where it'd be nice to maintain official support when it's not a burden (and it isn't).

IMO, not so much talking past each other as debating philosophy 🙂 I also don't care if we drop Python 3.8 support - I won't be doing the work, but I won't object if someone wants to.

It sounds like a big part of the pyupgrade stuff was typing changes. I'm a typing skeptic, and find the rapid pace of change in type annotations frustrating and annoying. So I tend to view things like this as evidence that the cost/benefit case for type annotations isn't necessarily as favourable as people like to claim. But as long as I can continue to ignore the whole thing and let someone else deal with it, I'm not going to worry.

[notatallshaw]

I'm honestly pretty confused here. I don't want us to consider anything BUT potentially dropping support for Python 3.8 this release. That is all, nothing more.

Sorry, I started this additional discussion, I should of been more explicit in my reasoning, my concern about urllib3 1.x support and Python 3.8 is that pip is unlikely to drop Python 3.9 support until some amount of time has passed since Python 3.8 support has been dropped, so it's more of a scheduling thing than a direct consequence thing.

I wasn't a huge fan of the size of the PR.

There's no way to avoid that when we increase the minimum supported Python while we have the upgrade rules turned on: #12936

We would either need to disable the pyupgrade rules or have a different minimum version of Python in ruff only to 3.8.

That may be part of the reason you got little interest

For me I was waiting for either release manager input or a consensues on #12989 before reviewing the PR, at a cursory glance it looked fine. But reading your response I'll confine any further discussion to #12989.

So I tend to view things like this as evidence that the cost/benefit case for type annotations isn't necessarily as favourable as people like to claim

I would agree with this if updating the typing syntax was manual, but almost all updates tend to be done by ruffs auto fixer. And while ruff is a relatively young tool, it is widely deployed by open source and closed source projects, I have a lot of trust that if the fixes are automatic that they have a high degree of safety. My main point for reviewing a PR like this would be seeing there are distinct commits where auto fixing is used and where manual fixes need to be applied.

[pfmoore]

I created #13236 to discuss the pyupgrade rules, and whether we should automatically apply them when we desupport a Python version.

[pfmoore]

As a quick note, I'm planning on aiming for mid-April for the release, probably the weekend of 19/20 April. That's about 6 weeks from now. My plan is that I'll release what's on main at that point. I'll check the 25.1 milestone regularly and remind people where necessary to get things merged, and I'll help where I can to do so, but I will not hold the release up because something isn't ready - I'll just move it to the 25.2 milestone.

Once the release is done, I'll allow a week or two for any showstopper issues to appear, but I will expect to declare 25.1 complete by the end of April. After that point, fixes for any further issues that might arise will need to go into 25.2.

If anyone has anything they really want to get released in 25.1, get it completed and merged as soon as possible 🙂

[ichard26]

There are two PRs I'd like to review. The former may/probably will be deferred in favour of waiting until the packaging wheel filename APIs are stabilized. The latter is conditionally approved, and waiting on my review. I expect some back and forth on it, but unless I find major deficiencies, I'll try to get it in for 25.1.

• Fix pip cache remove pattern matching. #13094
• Introduce resumable downloads with --resume-retries #12991

Looking at the release milestone, there are a number of deprecations scheduled for pip 25.1:

1. Deprecate pip install --editable calling setup.py develop #11457
2. Deprecate and remove --no-python-version-warning as Python 2 is dead #13154
3. Remove support for installed eggs distributions #12308
4. Raise an error on invalid egg fragments #13157

2 is trivially easy (there's already a PR), although honestly, I'm leaning towards simply removing the flag from the help output, removing the tests, and calling it a day. I don't want to cause breakage over small thing such as this flag.

3 is really @sbidoul's project. I'm unsure how ready we are to formally remove support for .egg based distributions. I'll note that this removal has been deferred numerous times. 4 is something I'd be happy to take on. I can't promise that it'll be completed in time though. The deprecation can't be finished until editable VCS requirements support the Direct URLs syntax. In essence, I'd need to revive PR #9471.

1 is the tricky one. Currently, there hasn't been much progress on actually removing support for legacy editable installs. I did do some early prototyping work, but I didn't make much progress, and frankly, I am not experienced enough to see it through completion. Unless @sbidoul (who did some related work not too long ago) wants to drive this forward, it will probably be pushed to 25.2.¹

Otherwise, there are some other (smaller) changes I'd like to get in, but they aren't time sensitive, so I won't spend the time to enumerate them here. If they happen, great! If not, so be it.

Footnotes

1. And to be honest, again, I don't mind pushing back the removal even further. This is likely going to be one of the more disruptive deprecations (at least since I joined the core team, I'm aware that the new resolver and PEP-517 rollouts were particularly disruptive 😅). I'd rather give our users a longer period to transition. The cost of keeping the legacy mechanism isn't that bad, especially as pip isn't in the midst of major development. ↩

[sbidoul]

I'll happily take care of legacy editables (#11457) and egg ditributions (#12330). Either do it or postpone.

If there are opinions on whether or not the time has come to remove these I'm all ears.

Regarding legacy editables, and removal of setuptools specific code paths in general, I'm personally in favor of pushing those actively, as I think the cases where pip falls back to the legacy code paths tend to create more and more confusion. And in practice the setup.py install removal did not seem to create that much disruption? One problem here is that setuptools has not progressed on a new config settings and better UX as a replacement of --global-options and --build-options, and in #11859 we were waiting for that.

Regarding egg distributions, I don't know. While pkg_resources is vendored, it is not a big maintenance burden. It does affect performance a little bit, though, due to having to import pkg_resources, even for the importlib backend. May be we could keep it until we drop python 3.10 support, since python 3.11 is the first one that uses the importlib.metada backend by default. So we could then completely drop pkg_resources support (and therefore discovery of installed egg distributions) when we stop supporting python 3.10.

[pfmoore]

I'm also happy to see removal of legacy editables moving forward. I'd like to see those code paths removed, and honestly I doubt much will change if we wait. At best, setuptools might improve their config settings support, but frankly I doubt it, and I think people no longer having the fallback of legacy editables is more likely to push them to improve things than anything else we can do.

Your suggestion of how to handle egg distributions seems reasonable to me. It doesn't feel urgent to remove it, although if someone wants to get it done sooner, I won't object.