r/Python • u/ichard26 Python Discord Staff • Jul 31 '26
News pip 26.2 - --only-deps, --no-require-hashes, venv isolation, and more!
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)_PROXYand similar non-pip specific proxy environment variables via--no-proxy-env - Separation between regular and build constraint (use
--build-constraintinstead)
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!
31
u/Justist Jul 31 '26
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).
3
u/flying-sheep Aug 01 '26 edited Aug 01 '26
uv isn’t straight-up better. E.g. pip uses
git clone --filter=blob:noneforgitdependencies, 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’llfetchjust the changes on subsequent clones of the same URL, but that has a different disadvantage for large repos, as they’ll blow upuvs cache)
50
7
u/Ivan171 Jul 31 '26
Is pip still leaving unused dependencies behind when uninstalling packages?
10
u/Mehdi2277 Jul 31 '26
That will probably be true forever. pip is not a tool that manages/tracks your environment.
18
u/zurtex Jul 31 '26
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.
10
u/bacondota Jul 31 '26
People saying that they don't use pip. Do you use uv in production? Like do you have uv on your docker?
37
22
u/skjall Jul 31 '26
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.
5
u/caks Aug 01 '26
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:
1
u/Electrical_Fox9678 Jul 31 '26
Care to share an example Dockerfile?
7
u/cointoss3 Jul 31 '26
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.
13
9
2
u/nat45928 Jul 31 '26
Yes, they have example dockerfiles that are very efficient in space and build time.
1
u/burlyginger Jul 31 '26
It's part of our multistage build but it's never installed on the container.
It's mounted from another image.
0
u/ColdPorridge Jul 31 '26
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.
18
u/cointoss3 Jul 31 '26
I forget pip is even a thing anymore. I haven’t used it in what feels like forever.
26
5
u/Drevicar Jul 31 '26
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.
-20
u/PixelPhoenixForce Jul 31 '26
pip in 2026? lmaooo
3
-3
u/shinitakunai Jul 31 '26
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
7
2
u/ase1590 Jul 31 '26
uv venv
uv pip install
uv runOnly three commands you need to hit the ground running.
1
u/shinitakunai Aug 01 '26
2 more than I need usually, since pycharm creates venvs automagically anyway
1
u/ase1590 Aug 01 '26
The uv managed venvs got the fast speed benefit uv brings for installing dependencies lightning fast.
-1
115
u/zurtex Jul 31 '26 edited Jul 31 '26
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).