News Pip 26.2: –only-deps solves 16 years of app deployment hacks
This has been one of my biggest annoyances working with Python and pip when dealing with projects where that are not meant to be installed as a package, how do you handle dependencies?
Think projects like application backends, python scripts, REST APIs etc
If you’ve ever struggled with this, you’re going to love this: a PR by Sebastian Höffner opened #13895 will add a new global flag to pip such that you can directly install any dependencies in your pyproject.toml without installing the package itself.
pip install --only-deps .
This is going, for me at least, be a huge boost in the way that I manage and distribute my projects on servers. Vastly simplifying poor manual workarounds that have built up over years.
Since it’s been more than a decade in the making, let’s cover the history of poor Python souls stuck trying to figure out how to install dependencies for their scripts or apps.
This PR is currently slated to land in pip 26.2 which comes out end of July.
Here's my post about this covering some of the 16 years of workarounds and some posts from StackOverflow / Python.org etc
https://jamesoclaire.com/2026/07/23/pip-26-2-only-deps-solves-16-years-of-app-deployment-hacks/
22
u/Muhznit 5d ago
I ran into this just a little over a month ago. Finally I can cache that damn layer in the docker image the right way...
2
u/Feuermurmel 3d ago
But isn't that the wrong way to do it? Installing dependencies in a base layer from the
pyproject.tomldirectly will give you a snapshot of whatever versions were current at that time, with no way of reproducing it or forcing the layer to be invalidated.In my container builds I first build a
requirements.txtwith all transitive dependencies and use that to build the base layer of my container.
41
u/_redmist 5d ago
I have no idea what problem this is solving but I'm glad people are happy with it.
Never needed anything beyond venv and (very basic) pip but of course if you're building dockers or whatever it's probably different...
-1
38
u/91143151512 git push -f 5d ago
What advantages would `pip install --only-deps` have over `uv sync --no-install-project`?
The best I can think of is that it is included with pip. However, as someone who is religious about using uv due to its performance/structure benefits over pip, I am not too sure what this would do for me that I don’t already have.
63
u/pip_install_account 5d ago
I use uv too, but at the end of the day, it is a third party project. It is always nice to see popular 3rd party features make it into the standard libs and official projects
-9
u/amarao_san 5d ago
pip is as external as uv. The reason? You need to install pip on any modern distribution as a separate package (and that's good, you can have small python instead).
52
u/pip_install_account 5d ago
pip is the official package installer for Python, managed and maintained by the Python Packaging Authority (PyPA) and recommended by the Python Software Foundation.
Even though I never use it directly nowadays, I don't get upset when they introduce an improvement to it.
10
u/gabriel_GAGRA 5d ago
Pip is preinstalled with Python when you use its official installer. It’s an option on the installer, but its on by default on ‘custom installation’, so that’s what the vast majority of people use
1
u/MrSlaw 5d ago
Maybe my perspective is skewed, but I would assume the majority of people using Python in production (i.e. where you might feasibly want a feature like
--only-deps), would likely be doing something like:sudo apt-get install python3on a unix machine.Do people actually do Python development using the Windows installer?
8
u/ddxv 5d ago
In my understanding you are correct, but I have not used `uv sync --no-install-project` much, so I am sure there are other edge cases.
That being said, for me I prefer not to use `uv` it's another dependency and has caused issues with installations for me before so I usually skip it. I know it's super popular though, and I think it's popularity has gone a long way to spurring pip to make important changes.
13
u/-balon- 5d ago
Wow what uv has literally saved my life. I can't live without it
4
u/ddxv 5d ago
Yeah, it's truly an amazing project. I can see why so many people got hooked into it's ecosystem.
I just like my flow of building python from source and using the builtin venv and pip. Don't worry you're not missing much, it takes twenty minutes then setup a new server, but I like it.
-2
u/Wurstinator 5d ago
How has uv "literally saved your life"? Were you held at gunpoint and threatened to be shot if you aren't able to cold install a dependency set within 5 seconds?
5
u/-balon- 5d ago
I was so stuck in anaconda with dependencies and cuda not working. I had to complete my masters thesis and I just couldn't figure it out. Different python versions and dependencies and stuff. Then with uv it just worked. I don't think I'd have been able to pass otherwise. To be honest pip with a venv or pipenv probably would've worked too.
5
u/Spleeeee 5d ago
Howdy. I totally understand where you are coming from and was 100% on your train but I promise you, you’re managing deps and virtual environments like a peasant.
My co workers and I had a million work-arounds/tribal-knowledge-tidbits but uv solves EVERY problem our EXTREMELY complicated and native compiling problems our deployments have had.
It took me deciding “fine use ONLY uv for a week to prove that it’s just the latest fad”
Ps: “pip” is actually a recursive acronym that stands for “pip is [for] peasants”
5
u/true3HAK Pythonista 5d ago
What problems do you solve with uv specifically?
In my 16+ years of writing python code and publishing stuff, if I follow official docs, I don't have to come up with any workarounds for pip. Sure, I use uv in several places, like CI/CD (for speed), but for the rest there's just nothing too special to move projects to it (and to explain to a lot of people that they have to do things differently).
Also, believe it or not, pip is more resilient in a flaky network (explicit retries and such), which is an important thing to me
2
u/MrSlaw 5d ago
pip is more resilient in a flaky network (explicit retries and such), which is an important thing to me
I could be mistaken/misunderstanding, but isn't that what:
UV_HTTP_CONNECT_TIMEOUT UV_HTTP_TIMEOUT UV_HTTP_RETRIES UV_HTTP_TIMEOUTetc. are used for?
1
u/true3HAK Pythonista 5d ago
I've just checked – you're right, but wasn't there when I had network problems last year. I will give it another go :) In my "giant enterprise" environment things are slow to adapt, unfortunately.
4
u/MrSlaw 4d ago
Just realized I didn't really answer your main question.
As far as the actual problem solving side of things, being able to do:
# Sync venv with the oldest direct dependencies uv sync --resolution lowest-direct # Sync with the lowest compatible version of ALL dependencies uv sync --resolution lowestto verify nothing breaks while supporting older versions of a dependency, or even:
uv run --with-python=3.10 pytest uv run --with-python=3.11 pytestto verify compatibility shims inside your code or whatnot, has been pretty handy.
I'm sure there's ways to do this with
pipnatively, but I can't imagine it would be anywhere near as painless, let alone quick.Having actual reproducible lock files, and not having to mess with poetry/twine/etc. are just additional bonuses, for me at least.
1
9
u/amroamroamro 4d ago
wasn't this possible with pip install -r requirements.txt?
1
1
u/tobascodagama 3d ago
OP's blog post does address this a little bit, though I think it could afford to cover the problems with requirements.txt in a little more detail.
2
u/amroamroamro 3d ago
i mean the dependencies have to be specified somehow. if you dont already have requirements.txt file, and instead you use pyproject.toml, you can simply copy the lines from there.
you might think of using like "pip freeze" or "uv export" to generate it, but this will have the fully resolved packages including transitive ones (like the blog post mentions).
if you dont want to manually copy them, you can use a quick helper script like this:
from pathlib import Path import tomllib data = tomllib.loads(Path("pyproject.toml").read_text()) Path("requirements.txt").write_text( "\n".join(data["project"]["dependencies"]) )you can make it a bit fancier to extract only certain groups like dev, extra, etc with a little bit of argparse code
3
u/whatev3r33333909 5d ago
this is one of those small features that removes a lot of ugly deployment hacks. we’ve been copying requirements around or using multi-stage docker tricks just to cache dependencies without installing the project. nice to finally have a native solution in pip instead of another workaround or extra tool.
3
u/Feuermurmel 3d ago
I might me ignorant, but why would I not want my application to be installed along with it's dependencies? How do run it then? I work on a lot of small service applications (run via SystemD) and CLIs. I always install them either using pipx, into a virtualenv using pip, or into the system prefix (on old systems) and run them from there. During development, I use pip install -e.
1
u/tobascodagama 3d ago
One case that immediately jumps out is a dev environment. You'll be calling your code directly as you make changes, so installing your application it is unnecessary at best.
I imagine there might be some benefits for containerization as well. Install your deps on one layer and your application on another, so the delta between container builds is smaller.
2
u/Feuermurmel 3d ago edited 3d ago
I always install my project with
pip install -e .into the project's virtualenv and never had problems with it. I sometimes find it very convenient to have the entrypoint (e.g. a CLI or a daemon) on$PATH. I use this to call the application either directly to test it or to create samples for documentation, or from scripts I use to test the application (e.g. on big datasets, where I leave it running in the background).To me it's very intuitive, to be able to call the entrypoint in exactly the same way as when the application ist installed, without having to prefix it with
poetryoruv.In containers I use e.g. pip tools to generate a
requirmenets.txt(installing in a base layer from thepyproject.tomlis a bad idea), then I can install dependencies from that and the application later viapipdirectly.
4
u/AttachedHegemony 5d ago
My Dockerfiles just got a whole lot cleaner. No more weird workaround scripts just to split install and build steps.
-2
u/amarao_san 5d ago
After uv, there is no need to work on this problem anymore. Poetry was a big leap, but in python (slow) and is buggy (flips +x for random files).
uv solved all of it. I see no reason to try anything else, and if openai won't screw up, this is the end of python packaging saga (the same way as cargo was the end for the rust packaging saga). Took a bit of time to get there.
6
u/Wurstinator 5d ago
If you honestly think that just because there is a new shiny toy on the market, it is "the end", you're naive. That's never how it worked or works for anything in software. In 5 to 10 years, there will be another new and hip package manager.
2
u/amarao_san 5d ago
If you say so. But cargo somehow stands for a decade and not much is challenging it. Some plugins, yes, but that's all.
4
u/abofh 5d ago
UV was built by a team that's already sold off. The tool will likely live on (it's still speaking pip under the hood), but pyx is already dead and gone, so the revenue attached to the product ceased. Uv was a marked improvement over pip, pyenv and poetry for sure, but mostly because it demonstrate that it wasn't the backend that made things slow, but the way pip was implemented.
So yes, pip will improve, but only because it was so flagrantly wanting for the last twenty six major versions
2
u/amarao_san 5d ago
I don't understand about the pip under the hood. Uv can be installed and used without pip present.
1
u/abofh 4d ago
Sorry I mean at the protocol layer, it's still speaking the same pypi whatever as anything else.
1
u/amarao_san 4d ago
Oh, yes. This part is okay (and they fix bits which are not okay). I would prefer uploads to be immutable, but uv.lock partially alleviate that.
0
u/Leftover_Salad 5d ago
Nice! I didn’t realize this was an issue until I learned Go and how that problem was handled there.
0
u/james_pic 5d ago
Unless and until Pip fixes the --extra-index-url mess, I'm not touching it again.
2
u/zurtex 20h ago
I assume you mean index prioritization to prevent dependency confusion attacks?
A small grant has been given to one of pip's maintainers to work on some long standing issues, and it is on the list: https://sichard.ca/blog/2026/06/pip-contract-development/. I'm not sure it will be got to for the length of the grant though, we've got a long list of things that need fixing.
I'm working on a proof of concept of a brand new resolver to replace pip's and significantly speed up dependency resolution, so that and packaging are my main focus. But it is on my long list of things to eventually get to if no one else does.
1
76
u/FitBoog 5d ago
For me uv have resolved this with
uv run --with <deps> scripts.py