Updates for part-time 2026 development

[ichard26]

This issue is a place for me to share updates for work completed in the summer of 2026. For more information, please read https://sichard.ca/blog/2026/06/pip-contract-development/.

Related work:

• Removing the legacy resolver #10946

[ichard26]

I've just finished my first day, so let's do an update!¹

I've spent a few hours working implementing build environment isolation via venv as an optional feature. I've got it fully functional with functional tests. I've checked and it does work with Debian/Ubuntu system Python as well 🎉. I just need to check for other distributions that may be missing venv. I'm planning to leave the remaining hours allocated to this feature for review and refactoring since that may be needed.

edit: you can see my work in progress here: https://github.com/pypa/pip/compare/main...ichard26:feat/venv-isolation?expand=1

Once I file a PR for this, I'll start work on the legacy resolver deprecation later this week.

Since the proposal didn't leave for a lot of discretionary time, I'm sticking to the work items listed in the formal proposal for any billable hours until further notice, but the nice thing is that I have a lot more motivation to do things on a volunteer basis as well (since anything particularly annoying can done as paid work). On this front, I've reviewed a bunch of PRs recently. I'm planning to take a look at PR #13895 soon.

And, for anyone who is confused about what this "paid work" is all about, please read this -- https://sichard.ca/blog/2026/06/pip-contract-development/

Footnotes

1. I won't be doing these every day, it just felt like a good way to start this work :) ↩

[ichard26]

End of week update:

• venv-based build isolation turned out to be a lot more complicated after some detailed reviews from from Damian's Claude instances. See feat: Add a venv-based build environment provider #14070 for all of the "fun" details
• I've spent some time digging through and familiarizing myself with resolvelib's and pip's 2020 resolver code to prepare for working on the deprecation and removal of the legacy resolver
  • Unfortunately, we didn't quite add all of the enhancements to the 2020 resolver so that we're ready to set a removal date for the legacy resolver by next release in accordance to this plan
  • This means I'll need to punt the communications work until after pip 26.2 is released
  • Next week, I plan on taking look at those the remaining feature gaps that block us from removing the legacy resolver and ideally file PRs
• I'm also going to spend some time next week looking into index priority. I probably won't be able to make much progress since this week got derailed by venv isolation, but I'd like to start ruminating and thinking through the feature soon (before I start writing things on paper!)
• Finally, we really need to discuss the future of pylock further, ideally during this release cycle

[notatallshaw]

I want to be voice now that I think the work that has gone into identifying what the issues are for migrating to venv, as our build isolation backend, are by themselves very valuable. Hopefully you can make significant progress towards implementation, but this was unlikely going to be an easy project.

[ichard26]

A quick status update: I took a look at PRs #13888 and #13904. I've mostly gotten them working, so the remaining work is to write a bunch of tests (because there are a lot of potential edge-cases here). I've also used this time as further opportunity to trace through and learn the resolver code.

Edit: oh and write new documentation because this part of pip's functionality is solely underdocumented.

[ichard26]

Last week summary

• Last week, I filed Prioritize editables over matching direct URL requirements #14101 after discovering a bunch of edge cases in pip's underspecified requirement handling
• I also ported my old wheel is incompatible diagnostic error branch to main and worked on it some more. It needs more refinement, but it's coming along well.

Screenshot

• I did the same for my network error branch and filed Add five diagnostic connection errors #14115
• I spent a tiny amount of time exploring and looking for current public uses of --use-deprecated=legacy-resolver.
  • It didn't look too bad TBH. There are a lot of hits, but most are in old projects, tutorials, or examples. I was worried that it would still be used regularly as a "break out of jail card" for broken dependency trees that cannot resolve to a consistent solution at all, but I've found very few such examples so far.

Looking at this week

I'm waiting on reviews for my PRs, so there isn't as much as I can do for venv-isolation or legacy resolver deprecation (I need opinions on #14101).

Today, I made the executive decision to spend some paid time explicitly on PR review. According to the original schedule, there wasn't any dedicated review time until 2ish weeks later, but IMO it's important to stay on top of PR review. I'd rather not review everything in the last two weeks before cutting pip 26.2.

• Handle invalid HTTP 304 responses when no cached file is available. #13956
• Reconcile PEP 658 sidecar metadata with the downloaded wheel #13991
• Fix Link.filename decoding URL path twice #14110
• Complete PIP_CONSTRAINT build-environment deprecation #14094
• Improve Windows CI sharding #14096
• perf(cache): use a set of tags for wheel cache lookup #14122
• Skip pip show installed-files list unless --files #14118
• Ignore negative Content-Length in file downloader #14119
• fix: skip wheel cache for local directory requirements #14080

For the rest of this week, I will continue work on improving errors (specifically unsupported wheel) and index priority. In addition, I want to look at #11440 and pip sync (at least in terms of giving any high level design/UI feedback so there is enough time to adjust before the release deadline).

In terms of scheduling, I will likely do ~4 hours tomorrow and then 2 + 3 hours on Thursday and Friday. I'm out of the house all of Saturday.

[ichard26]

Oh wow, it's been two weeks already. Time is flying! Here's a very belated update:

Two weeks ago

• Lots and lots of PR review! I didn't keep track of individual PRs, but there is a partial list from the last update
• Significant reworking of my "wheel is incompatible" diagnostic error

Last week

• More PR review
• Addressed Damian's (very thorough) feedback and landed Add five diagnostic connection errors #14115
• Testing and further refinement of the wheel error feature
  • It turns out that the best strategy is to rely on packaging to query information on the current environment because trying to do it yourself (even for seemingly obvious things) is a minefield.

Sneak peek

Looking at this week

I'd like to submit the wheel error PR once #14176 lands. This will almost certainly be the last major error improvement I will be including in pip 26.2. Improvements for "No distribution found for X" is going to take some time and I'd rather chip away at it more gradually.

I'm still waiting for reviews on PR #14101 which is the next step in the legacy resolution removal. (It should hopefully unblock #13904 which is also necessary.)

Throughout the week, I'll continue to chip away at whatever is left in the 26.2 release milestone: https://github.com/pypa/pip/milestone/84, notably actually finishing my review of --only-deps. (I did 80% of it earlier, but I got side-tracked and forgot about it.)

Finally, I also have direct communications in regards to pip I need to get to this week. I'll be following up directly soon.

"So much for plans"

As you've probably noticed, there is no mention of index priority in here. There are two reasons for this:

• I haven't had the time or opportunity to work on index priority because of pretty none of the error work has gone to plan 🙂. All of it is highly non trivial, and in particular, the agentic reviews are finding so many subtle/non-obvious issues that I wouldn't have thought of¹². Needless to say, the original time estimates have all been thrown out the window.
• There has been less review capacity than I was hoping for. I'm wary of starting a new design discussion on a significant feature like index priority when I'm already waiting on reviews/opinions on resolver removal/error work.

I will look at index priority in some shape before the release, but serious progress seems unlikely until after the release and we have a bit more breathing room.

In addition, to make some progress while I wait for more eyeballs on the resolver removal PRs, I'm planning to start drafting material for the outreach/communication work in advance, so when we're ready to commit to a date (whenever) I'll be prepared.

Footnotes

1. So much for the overhyped "agents will make you ship code faster" sentiment... ↩

2. To be clear, this is a good thing! Fixing more bugs during the PR review process is a lot better than having to fix them after a release and issuing hotfix releases (especially as the RM!) ↩

[ichard26]

Last 1.5 weeks

• Research and follow up on a security report we received from a member of the community
• Preparation for filing wheel error PR -> refactor: Split exceptions into a package #14176
• So much PR review 🙃
• Manual verification and developing an improved patch for editable constraint and editable prioritization: Prioritize editables over matching direct URL requirements #14101. Note: this PR is deferred until after release 26.2 since there's some subtlety in the implementation

This week

• Release pip 26.2, publish a release post, and handle any post-release fires
• Connect with urllib3 to see if we can find a better way forward for the truly awful retrying warnings: Improve network error message #8641
• (and if I have time, return to PR 14101)

[ichard26]

Last two weeks

• I published release 26.2, a hotfix 26.2.1 (ahem), and hopefully the release will be properly done by EOD tomorrow
• Filed Add an unique extra attribute to retrying warning (so pip can rewrite it) urllib3/urllib3#5140 and created a nearly-ready branch for pip. I'm waiting for urllib3 to cut a new release which should come within a few weeks
• I took another look at the editable priority and constraint code and did find issues with Prioritize editables over matching direct URL requirements #14101 (replacing resolver candidates is a dicey business). I'll see if I can rework it or not.
• I just filed Switch to auto-updating spinners wholesale  #14238 and after inspecting and verifying that the status reporting between the subprocess and inprocess build dependency installers are now similar
• Direct conversations with regular contributors and the committer team

New priorities

In between cutting pip 26.2, I had some conversations with Damian on the PyPA Discord. We were chatting about pip feature development, dependency resolution, and lockfiles. Eventually, we were talking about index priority and how it'd be even larger rabbit hole than the experimental features I've been working on so far (inprocess-build-deps and venv-isolation).

I was hoping that the simpler, global options that uv has for index priority (or rather, they call it index strategy) would be an OK fit and could be ported over to pip. However, I was informed that "[index strategies] that uv has generally aren't a good UX, [and] most users who use multiple indexes just end on turning on the unsafe option" (which largely defeats the point of index priority).

The real solution for index priority is to well... to support per-package index pinning... which requires pip to support per-index configuration... which is dependent on pip gaining support for project level configuration. That's all to say that this is even more complicated and is blocked on even larger work items/open discussions in pip.

While there is an alternative pathway where we implement something akin to uv's index strategy, the effort spent on that doesn't seem like the best investment of time, given their limited utility in most situations. So, I've decided to pivot towards spending more time to review and stabilize inprocess-build-deps and venv-isolation. venv-isolation is actually mostly OK and I am fairly confident it's ready, but I don't have the same confidence in inprocess-build-deps (which came before I had paid engineering time).

I'd like to review the feature's output handling and the code overall for any edge cases. The code works fine -- I know that from mine and Damian's earlier testing -- but as Claude/Codex have proven adept at finding, there are likely many edge cases to be ironed out. I'd much rather spot and fix these edge cases early instead of requiring a few releases (and possibly bugfix releases) to stabilize naturally.

In addition, internal refactoring is needed to fully support inprocess-build-deps and venv-isolation being enabled together (they work 99% of the time, but the 1% is just completely broken). I'd like to take a look at that, too.

This upcoming week

PR #14238 is the first product of the new effort to review and improve inprocess-build-deps. I'm planning to review the rest of the code (manually and via automated means) next. I'd like to also prototype the refactoring needed to enable inprocess-build-deps and venv-isolation together.

Later in the week, I'll come (yet again) back to #14101 and see what I can do.

Finally, I'm planning to review the PRs that improve dependency resolution errors so I can start work on my own improvements to no distribution found errors.

[ichard26]

The formal contract period has concluded so I'm no longer working on pip on a part-time basis. I still have things I'd like to do, but I won't make any promises when they will be complete. I will be prioritizing getting open PRs of mine landed, however.

As promised in the original proposal, I've written a public post discussing what was delivered, what work remains, and the reflections I have. https://sichard.ca/blog/2026/08/pip-contract-finish/