+-----------------------------------------------+
|The views and thoughts below are purely my own.|
+-----------------------------------------------+

This post was written 2026-02-11

pip-tools v7.5.3

Today we released pip-tools v7.5.3!

It’s a patch release – so as you might expect, it’s mostly bugfixing – but it does feel to me like a milestone. Not only is it the first release of 2026, but some of the behind-the-scenes work we’ve been doing is starting to pay dividends.

Thanks to Contributors, New and Old! (but also slop…)

Like many other FOSS projects, pip-tools is indebted to its contributor community. We try to make the project welcoming to new folks, and a decent chunk of our work is always focused on the contributor experience.

We got commits from a couple of new people this cycle, which always warms my heart.

But also, between 7.5.2 in November 2025 and 7.5.3 (now) in February 2026, we have started to attract notably more slop contributions. Not as many as some other projects, but a marked increase. It’s a drag, but I’m determined not to let it harm the welcoming nature of the project. We’re looking at what others are doing and are drafting our own policy on the use of LLM tools. (Feel free to follow along!)

Notable Changes

The best way to understand changes as a user is to look at the changelog.

Python Support, -3.8, +3.14(t)

We dropped Python 3.8 support this cycle, and added tests on 3.14 and 3.14t.

I’m somewhat looking forward to dropping 3.9 . We’ll probably take our cues on that from pip. But removal of 3.8 means we can safely rely on __class_getitem__ on the builtin collection types being available at runtime, so I care much more about it than 3.10 features.

To me, this is mostly a pain for maintainers. If you don’t test locally on 3.8 it’s very easy to push an update which will fail on that version in CI. With 3.8 gone, one of my personal tripping hazards is removed.

So, hooray!

pip v26.0 is supported

Internally, we added a new subpackage at piptools._internal._pip_api to wrap our compatibility interactions with pip. It’s part of a slow migration away from a really large “junk drawer” utils.py module, which is hard to maintain due to its lack of structure.

When pip v26.0 released, we got a chance to put it to the test. Did it really make supporting the new pip version easier?

Well, it’s hard to say for sure, but it took only 4 days after pip v26.0 released to work through the compat issues, and the new code is all unit tested properly and abstracts over any pip version detection.

I think we’re on good footing going forward.1

Temp File Leak

pip-compile -r - had a buggy behavior reported to us via email as a security vulnerability (on the day I originally was planning to prep the v7.5.3 release!).

When reading from stdin, pip-compile writes data to a temporary file so that it can be referenced multiple times. Because of the way Windows temporary files behave and the fact that pip-compile is invoking pip on the file (so we don’t fully control all of the code which will open and read the file), we need to disable the normal delete=True behavior we get from the tempfile module.

The buggy code correctly set delete=False, but then incorrectly didn’t have handling to cleanup the file later.

This is definitely a bug. Is it a security bug? I don’t think so. The issue was presented to us as

$ while true; do echo 'six' | pip compile -r -; done

resulting in a DoS because you run out of disk space.

I can imagine a more complex system like Dependabot or Renovate in which users of a system can trigger a call to pip compile -r - being impacted. However, the while true loop is obviously a contrived example. It’s difficult to imagine a realistic usage of pip-compile which can be maliciously manipulated into running users out of disk space.

Email or DM me if you think I should reconsider. (And maybe tell me how you’d do the CVSS score for this. ;)

Release Kerfuffle

When we actually pushed the buttons to release v7.5.3 , our release CI job hit a snag on changes we made in this cycle. We had to delete the tag and release, and retrigger the whole thing once the CI job was fixed.

We’re continuing to work on enhancing our CI setup, and we want to get to a place where the release process is pretty much push-button.

When we next have changes like this which can’t be tested until release time, we’ll likely publish an alpha first, to kick the tires and make sure everything works.

Personal Notes & Retrospective

I’ve been getting deeper into the pip-tools codebase over these past few bugfix releases. Nothing builds mastery quite as quickly as having to fix things!

It’s enormously satisfying to see the positive impact when we ship a new release, especially these unexciting releases which “just” fix compatibility issues so that people can keep on using their existing workflows.

That’s all for now. Catch y’all next time!

  1. Within the realm of what’s possible. pip-tools imports things directly from pip. We won’t be on really good footing until or unless we can find a path forward which avoids that. ↩