Release 25.0

[ichard26]

I'm filing this early, but given the current pace of development, it can't possibly hurt :)

Looking at the current state of the milestone, there are a handful of deprecated features scheduled for removal during this release cycle:

• Removal of egg support entirely (Remove additional detection of installed egg distributions when using the imporlib.metadata backend #12308) [actually scheduled for pip 24.1]
• Removal of --build-option and --global-option (Remove --global-option and --build-option flags #12301) [deferred]
• Removal of the legacy editable install mechanism

There's also the upgrade to vendoring 1.1.0 which will bring significant improvements.

@sbidoul, is setuptools any closer to being prepared for the removal of --build-option and --global-option?

[ichard26]

Oh! and how I could forgot the last major potential change: removal of Python 3.8 support. I haven't looked at the numbers recently, but we need to consider that as well.

[sbidoul]

is setuptools any closer to being prepared for the removal of --build-option and --global-option?

I don't think so. I filed #13106 accordingly.

[ichard26]

For whoever decides to be the next RM, just a heads-up: we'd like to switch to using an action to build (not prepare) and push the release, using Trusted Publishing and all of the new fancy stuff that comes with that. See #13048.

[ichard26]

Looking closer at my schedule, I will be too busy to be a RM right until January 30 next year, so if there is no one that is able to be the RM, I could do it on either a tight schedule (aka that weekend) or push the release by a week or two. Of course, I'm also new at this, so I'd definitely want to have a former RM available for questions :)

[sbidoul]

I'm happy to take on the RM hat for this release again. I'll take the opportunity to test and document the trusted publisher workflow.

[ichard26]

I'm planning to spend time starting this Friday on the legacy editable install removal.

• The actual PR removing support for legacy editables - I'm rather unfamiliar with this part of the codebase, so I'm probably going to need help, but I'd like to at least try to take a stab at this
  • Ensuring that the error messaging is crystal clear and provides user-friendly actionable advice
• A bunch more communication work
  • Rewriting all of the things I've said about this deprecation into a single blog post that is focused on this deprecation for better SEO (over my pip 24.2/24.3 posts)
  • Write a StackOverflow Q&A for the eventual error
  • Write a documentation page for this...? (I may use this as an excuse to finally set up the error index we've been meaning to set up)

I'm still relatively unfamiliar with the codebase, so I've decided that I can best contribute by working through the admin and communication work needed to support this release. Historically, this project hasn't done the best w/ communication (barring the time we had a paid PM) and I'd like to improve that if I can :)

[ichard26]

I do want to take another look at the open PRs and see if there's anything else I'd love to see in the next release, but for now, maintainer eyes would be appreciated on the following issues/PRs targeting 25.0

• Vendor resolvelib 1.1.0 #13001
• Add trusted publisher release workfiow #13048 (I do realize that I need to reply myself)
• Never use pkg_resources metadata backend on python 3.14+ #13010
• Drop support for Python 3.8 #12989

[notatallshaw]

I've been testing complex resolutions on main and I've found some examples that can install different versions compared to 24.3 due to pypa/packaging#794

In particular several Google packages have a habbit of having the requirement of the form foo<2.0dev, this now implies a pre-release for versions less than 2.0, e.g. 1.9rc1. This is spec compliant but probably unxpected by users writing this.

For this example I think they inteded foo<2.0, which according to the spec still does not allow for 2.0 pre-releases, even with --pre, but doesn't imply prereleases for earlier versions.

As discussed on discord, this should be noted in the changelog / release notes, let me know if you want me to write up something specific, or if this is clear enough?

[ichard26]

Do we still want to include the removal of legacy editable installs in pip 25.0? I haven't had much time to work on pip, and I don't expect that to change until February. I did start the removal PR, but it will need significantly more work by someone else. I haven't made any changes to fix the test suite, and the error handling will need more thought. Given it's almost mid-January, this could easily end up being rushed.

In addition, I'm willing to wager this removal will result in a non-trivial amount of disruption and outcry. While that's inevitable, it would be better to go through that process when pip isn't operating on such limited maintainer capacity IMO.

This has been complicated by the fact all of the current communication is clear this removal is scheduled for pip 25.0 (oops, that's my fault), but I'd prefer a smoother removal despite the possible confusion, even only to avoid burning through our churn budget unnecessarily and my sanity!

[sbidoul]

I plan to release on the week-end of January 18/19 or 25/26.

Do we still want to include the removal of legacy editable installs in pip 25.0

@ichard26 I personally read the gone_in mention as "not earlier than", so I'm fine with postponing. And it's probably best to not rush this and take our time to review and test properly.

this should be noted in the changelog / release notes, let me know if you want me to write up something specific, or if this is clear enough?

@notatallshaw It's clear to me, but if you find the time to create a PR with a news entry for that, it would be helpful! If not I'll come up with something.