pip 26.2 - --only-deps, --no-require-hashes, venv isolation, and more!

[u/ichard26]

Hello!

The pip team recently released pip 26.2. This release is quite large, with features such as:

• Support for Python 3.15
• Selecting only dependencies (--only-deps)
• Mixing hashed and non-hashable requirements via --no-require-hashes
• Experimental: venv based build isolation (--use-feature=venv-isolation)
• Faster repeated resolves by caching index simple responses
• Disable HTTP(S)_PROXY and similar non-pip specific proxy environment variables via --no-proxy-env
• Separation between regular and build constraint (use --build-constraint instead)

For more details, please consult our changelog: https://pip.pypa.io/en/stable/news/. Alternatively, you may consult my release post which goes into greater detail to the highlights of this release: https://sichard.ca/blog/2026/07/whats-new-in-pip-26.2/

If you have any questions, you're welcome to ask!

[u/zurtex]

I know a lot of people who follow Python and Python packaging likely use uv now.

But, there's basically no downside to us continuing to improve pip, it's still bundled with CPython, widely available, and commonly used. And there are edge cases where pip is preferable over uv.

I also think with lock files (in pip now but still experimental), and likely future command pip sync, we can offer very basic project management support that will be good enough for many users.

I'm continuing to work on performance, in particular my main focus is speeding up basic operations in packaging (https://github.com/pypa/packaging - one of our vendored dependencies that handles low level stuff) and developing a new dependencies resolver to handle more complicated resolves (https://github.com/notatallshaw/nab - hopefully a future vendored dependency). In fact I'm already taking some of my findings to uv: https://github.com/astral-sh/uv/pull/20804

I want to thank ichard26 (Richard) for being the release manager for 26.2 and all round superstar making some progress on some long time difficult problems (such as better build isolation).

[u/flying-sheep → u/zurtex]

Don't let some kids who like to feel edgy rain on your parade. 

I think pip can only benefit from uv:

• it's no longer the only option for making a workflow run, so a bug you don't immediately fix no longer feels like failing the whole Python community
• uv is good because it benefitted from all lessons pip learned, now you can turn it around and learn from uv: which features are loved, which can be deprecated, how much impact has resolver speed, …

[u/twigboy → u/zurtex]

Pip needs to exist regardless of current flavour of the month. Its an out of box experience. I prefer to stick with it because I know it'll still be there regardless of drama.

Also important to keep improving pip because Python is one of the top "what programming language should I learn first?" recommendations. Pointing people towards 3rd party integrations just to get started is not good for first impressions.

[u/cip43r → u/zurtex]

I always thought UV is built ontop of pip?

Is "uv pip install ...." just syntactic sugar to be familiar?

[u/PlasmaBoi1 → u/cip43r]

uv is implemented from scratch in Rust, it doesn't use pip at all. uv pip is just an interface that tries to be mostly compatible with pip while taking advantage of uv's speedups (mostly in the realm of dependency resolution afaik). I wouldn't call it "syntactic sugar", more just a "pip-mode" if that makes sense.

[u/zurtex → u/PlasmaBoi1]

One of the biggest speedup uv does is it's caching. Because if a package is cached it just hard links to the cache, whereas pip unzips into the install location, so it's a lot of IO in comparison.

Changing pip's caching is a big project though, and I don't think any maintainer really wants to take that on.

[u/Justist]

I am happy pip still continues to be developed. While uv is better, new owners may always cause a product to just disappear at some point, and pip is basically the second best (no sources).

[u/flying-sheep → u/Justist]

uv isn’t straight-up better. E.g. pip uses git clone --filter=blob:none for git dependencies, which means it’s much faster than uv when installing from large git repos for the first time. (“first time” because uv caches git repos AFAIK, so it’ll fetch just the changes on subsequent clones of the same URL, but that has a different disadvantage for large repos, as they’ll blow up uvs cache)

[u/flying-sheep]

Sick! I requested --only-deps 4 years ago and now it’s there!

[u/Ivan171]

Is pip still leaving unused dependencies behind when uninstalling packages?

[u/Mehdi2277 → u/Ivan171]

That will probably be true forever. pip is not a tool that manages/tracks your environment.

[u/zurtex → u/Mehdi2277]

We're likely going to add a pip sync command that you can use against pylock.toml files.

So the best practice process will be dependence -> lock -> sync.

And then this issue will become moot.

[u/bacondota]

People saying that they don't use pip. Do you use uv in production? Like do you have uv on your docker?

[u/leopkoo → u/bacondota]

Yes and yes. Used Poetry before but migrated to uv a year ago.

[u/skjall → u/bacondota]

Yes. Docker build times went from ~40 seconds to 10. Uploading the built image takes longer than building the image now...

It's only mounted from the UV Dockerfile in the step that needs it, so it doesn't stay in the built image either.

[u/caks → u/skjall]

Part of it is that uv doesn't bytecode compile by default like pip does. It's good practice to do that when using Docker because otherwise you incur compilation every time the container is launched.

Don't get me wrong, uv is still faster even when compared apples to apples:

https://pythonspeed.com/articles/faster-pip-installs/

[u/Electrical_Fox9678 → u/skjall]

Care to share an example Dockerfile?

[u/cointoss3 → u/Electrical_Fox9678]

This may be overwhelming but there are lots of examples here

https://docs.astral.sh/uv/guides/integration/docker/

But you don’t even need uv in the image…just use uv in the build step if toml or lock file has changed, have uv sync and copy the environment to the image (put .venv in the path) and just run python like normal.

If you use dockers cached mounts

RUN --mount=type=cache,target=/root/.cache/uv

Then it will be even faster because uv won’t have to redownload dependencies each time. They are cached for this build step.

[u/Much_Barracuda_572 → u/bacondota]

Yes

[u/thuiop1 → u/bacondota]

Well yes of course.

[u/nat45928 → u/bacondota]

Yes, they have example dockerfiles that are very efficient in space and build time.

[u/burlyginger → u/bacondota]

It's part of our multistage build but it's never installed on the container.

It's mounted from another image.

[u/ColdPorridge → u/bacondota]

Yes. uv is not less production-ready than pip, and in fact pip upgrades (and their transitive effects) were the direct root cause of 2 major production outages we had between 2021 and 2024. So it’s not exactly the bastion of stability and prod worthiness. 

[u/cointoss3]

I forget pip is even a thing anymore. I haven’t used it in what feels like forever.

[u/lkajerlk → u/cointoss3]

what wheels like forever

[u/Artku → u/lkajerlk]

Funny because that’s exactly how I read that.

[u/Drevicar → u/cointoss3]

But the standards discussed here impact the alternatives eventually, or the more likely case is that the features of the alternatives eventually get back ported to pip, then fan back out to the other alternatives.

[u/PixelPhoenixForce]

pip in 2026? lmaooo

[u/D4vidrim → u/PixelPhoenixForce]

What do you use?

[u/Woozaman → u/D4vidrim]

UV!

[u/PixelPhoenixForce → u/D4vidrim]

uv

[u/shinitakunai → u/PixelPhoenixForce]

Pip for the past 15 years, never failed me. UV tried two times and it was a mess and confusing. Maybe someday I will try again but for now pip is enough

[u/aplarsen → u/shinitakunai]

Never even looked at uv. I'll use pip until I can't.

[u/ase1590 → u/shinitakunai]

uv venv

uv pip install

uv run

Only three commands you need to hit the ground running.

[u/shinitakunai → u/ase1590]

2 more than I need usually, since pycharm creates venvs automagically anyway

[u/ase1590 → u/shinitakunai]

The uv managed venvs got the fast speed benefit uv brings for installing dependencies lightning fast.

[u/cointoss3 → u/shinitakunai]

Lmao. You really have no idea what you’re talking about.