9 ms·
Uv overtakes pip in CI
- sieabahlpark 11mo ago[dead]
- bognition 11mo agoThis shouldn’t be a surprise to anyone who has been using Python and has tried uv. Python dependency management and environments have been a pain for 15 years. Poetry was nice but slow and sometimes difficult. Uv is lightning fast and damn easy to use. It’s so functional and simple.
- ThibWeb 11mo agofor me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more
- bognition 11mo agoHonestly, I was skeptical when I learned about uv. I thought, just Python needs, another dependency manager… this was after fighting with pip, venv, venvwrapper, and poetry for years. Then I gave it a try and it just worked! It’s so much better that I immediately moved all my Python projects to it.
- zahlman 11mo ago> I thought, just Python needs, another dependency manager… this was after fighting with pip, venv, venvwrapper, and poetry for years. Pip, venv and virtualenvwrapper (people still use this?) are not meaningfully "dependency managers". A venv is just a place to put things, and pip does only basic tracking and tries to maintain a consistent environment. It isn't trying to help you figure out what dependencies you need, create new environments from scratch, update pyproject.toml.... Pip's core capability is the actual installation of packages, and uv does a far better job of that part, using smarter caching, hard links to share files, parallelized pre-compilation of .pyc files, etc. Basically it's designed from the ground up with the intention to make lots of environments and expect starting a new one to be cheap. Poetry, as far as I was able to determine, does it basically the same way as pip.
- sgarland 11mo agoI actually did use virtualenvwrapper quite a bit until uv. I had built up various shell aliases and functions, so it was fairly painless to create and manage venvs. uv just means that I don’t have to think about that part now.
- simonw 11mo agouv first came out 15th February 2024 so it's a year and a half old now. Still pretty impressive for it to get adoption this fast though.
- WD-42 11mo agoI think it’s been long enough now. Uv just has so much velocity. Pyproject.toml and pep support just keeps getting better. Poetry which I think is the closest analogue, still requires a [tool.poetry.depenencies] section afaik.
- greenavocado 11mo agoYou don't even need to edit any files yourself for most simple use cases. uv init uv add package uv run program.py That's it. If you inherit a codebase made this way from someone else, merely running uv run program.py will automatically create, launch the venv, configure packages, run your script, seamlessly on first launch. Uv lets you almost forget virtual environments exist. Almost.
- kstrauser 11mo agoYep. Poetry was such a delightful upgrade from pipenv, which we’d tested as an upgrade from bare pip, which didn’t have a dependency resolver at the time. If someone’s already fully bought in on poetry, that’d be the one case where I could plausibly imagine them wanting to leave well enough alone. For everyone else, just try uv and don’t look back.
- rtpg 11mo agouv having a good pip compatibility layer probably helped a lot, because you could try things out that way and see what fit, so to speak. It's probably worth mentioning that Astral (The team behind uv/etc) has a team filled with people with a history of making very good CLI tooling. They probably have a very good sense for what matters in this stuff, and are thus avoiding a lot of pain. Motivation is not enough, there's also a skill factor. And being multiple people working on it "full time"-ish means you can get so much done, especially before the backwards compat issues really start falling into place
- perrygeo 11mo agoThe pace of uv adoption is insanely fast. It's directly related to how bad the previous Python tools were/are. Even to seasoned veterans set in their ways - they still know a better solution when they see it.
- scuff3d 11mo agouv was really smart in the way they integrated with existing solutions. My whole team just switched over from pip, and it was painless. We were already using pyproject.toml files which made it even easier, but uv also has documentation for transitioning from requirements.txt files.
- lukeschlather 11mo agoI feel like I've tried at least 5 different package management tools for python. Between pip, poetry, pip-tools, pipx, I'm not really sure what easy_install, egg, pkg_info are, but I do know I have always been surprised I need to care. It sounds like uv is a drop-in replacement for pip, pipx, and poetry with all of their benefits and none of the downsides, so I don't see why I wouldn't migrate to it overnight.
- skylurk 11mo agoIt's a (better IMO) replacement for poetry, but not drop-in. Additionally it is a drop-in replacement for venv and pip-tools.
- andy99 11mo agoI’ll bite - I could care less about speed, that feels like a talking point I see often repeated despite other package managers not being particularly slow. Maybe there’s some workload I’m missing that this is more important for? I’ve tried uv a couple places where it’s been forced on me, and it didn’t work for whatever reason. I know thats anecdotal and I’m sure it mostly works, but it obviously was off putting. For better or worse I know how to use conda, and despite having to special attachment to it, slightly faster with a whole different set of rough edges is not at all compelling. I have a feeling this is some kind of Rust fan thing and that’s where the push comes from, to try and insinuate it into more people’s workflows. I’d like to hear a real reason I would ever migrate to it, and honestly if there isn’t one, am super annoyed about having it forced on me.
- morshu9001 11mo agouv is comparable to npm. All your deps get auto tracked in a file. There are other things that do this, but pip isn't one of them, and I vaguely remember the others being less convenient. The speed usually doesn't matter, but one time I did have to use it to auto figure out compatible deps in a preexisting project because the pip equivalent with backtracking was taking forever with CPU pegged at 100.
- cgearhart 11mo agoI’ve been trying uv lately to replace my normal workflow of selecting a python with pyenv for the shell, then making a venv, then installing a bunch of default packages (pandas, Jupyter, etc). So far the only benefit is that I can use just the one tool for what used to take 3 (pyenv, venv, pip). I don’t _hate_ it…but it really isn’t much of an improvement.
- gre 11mo agoYou've never waited 10 minutes for conda to solve your environment and then say it's unsolvable?
- andy99 11mo agoI have, but it takes me back many years to some obscure situations I’ve been in. For my day to day, I can’t think of the last time I’ve encountered it, it’s been years, and I regularly am setting up new environments. That’s why I’m curious about the workflows where it matters.
- anitil 11mo agoFor me the most convincing argument was that it took ~3 minutes to go from 'I wonder if I should give this thing a try' to 'oh it .... it worked!?'
- saghm 11mo agoAs someone who also hasn't really used any of the past 8 years or so of Python dependency management, it's nice that it seems to support using arbitrary other tooling as well. At some point recently I wanted to run something that happened to use pdm, which I hadn't even heard of, but I was able to invoke it with `uv tool run pdm` and not have to learn anything about how to set it up manually.
- tclancy 11mo agoYeah, been doing this for over twenty years and finally got a chance to start playing with it a few months back and was confused at how I got that far that fast.
- mnky9800n 11mo agoThis is how I explain it to the stragglers. Just try it because you will suddenly in about 1 to 3 minutes not know how to go back. Haha.
- ziml77 11mo agoIt really is! I switched to using uv just 2 weeks ago. Previously I had been dealing with maintaining a ton of batch jobs that used: global packages (yes, sudo pip install), manually managed virtualenvs, and docker containers. uv beats all of them easily. Automatically handling the virtualenv means running a project that uses uv feels as easy as invoking the system Python is.
- Balinares 11mo agoI just wish uv made it more straightforward to have arbitrary purpose-specific virtual environments, e.g. for building the package, for running the test suite, for dev tooling (PuDB ), etc. That's one thing pixi does better, I think.
- atoav 11mo agoStarted converting every repo over to uv. I had some weird and hard to deal with dependencies before. Every single one was easier to solve than before. It just works and is blazingly fast. Absolute no-brainer.
- walkabout 11mo agoIs this like when everyone on here had already been saying Yarn was a no-brainer replacement for npm, having totally obsoleted it, for like two-plus years, but it was still lacking safety/sanity checks, missing features, and broke in bizarre ways on lots of packages in-the-wild? Or is the superior replacement actually up to the job this time?
- kstrauser 11mo agoI’m certain there’s going to be so bizarre edge case where pip is fine and uv isn’t. It’s inevitable. However, in every situation where I’ve used it, pip is better than pip or poetry or any other package manager I’ve ever used. I just found out they’re still making pipenv. Yes, if you’re using pipenv, I’m confident that uv will be a better experience in every way, except maybe “I like using pipenv so I can take long coffee breaks every time I run it”.
- walkabout 11mo agoYeah, I’m just skeptical because I was at an agency in the heat of yarn-mania, waaaay after people online were proclaiming npm dead and pointless, and it went poorly enough that we developed a ha-ha-only-serious joke that you knew a project was properly in-development when someone had lost a half-day debugging some really weird error only to find that “npm install” instantly fixed it, and then switched the started-in-yarn codebase over to npm.
- kstrauser 11mo agoI could see that being traumatizing, but this really isn’t like that. Pip and uv and poetry and the rest don’t fundamentally change how a package is installed into a Python virtualenv. If `uv add foo` works, you could use the equivalent in any of those other tools and get basically the same result. You don’t have to know or care which tool is installing your project because that’s all invisible from inside the code you write.
- philipallstar 11mo agoThe Javascript tool wars were a lot more emotional and cargo-culty than anything in the Python space I can think of.
- hk1337 11mo agoIt’s a little too fast, I’m having trouble believing it’s actually doing anything sometimes.
- hyperbovine 11mo agouv is so over-the-top fast compared to what we're used to that I would argue it's actually bad for the language. Suddenly it dawns on you that by far the most capable and performant package manager (and linter) (and code formatter) (and type checker) for Python is in fact not written in Python. Leaves an odd taste. Makes you wonder what else ought not be written in Python ... or why anything should be written in Python. Here be dragons ...
- arcanemachiner 11mo agoTry not to cut yourself while grinding that axe. Python may not be the fastest language, but it's easy to learn, compilation times aren't an issue, you'll never have to fight the borrow checker, etc. Every language has its warts.
- tyg13 11mo agoIMO, Python should only be used for what it was intended for: as a scripting language. I tend to use it as a kind of middle ground between shell scripting and compiled languages like Rust or C. It's a truly phenomenal language for gluing together random libraries and data formats, and whenever I have some one-off task where I need to request some data from some REST API, build a mapping from the response, categorize it, write the results as JSON, then push some result to another API -- I reach for Python. But as soon as I have any suspicion that the task is going to perform any non-trivial computation, or when I notice the structure of the program starts to grow beyond a couple of files, that's when Python no longer feels suitable to the task.
- Grimblewald 11mo agoAlso great for rapid prototyping, but one needs to be real with oneself, it is a prototype.
- WhyNotHugo 11mo agouv is weird. It's like 5 entirely different tools mashed and entangled into one program. Last I tried it, it insisted on downloading a dynamically linked Python and installing that. This obviously doesn't work, you can't distribute dynamically linked binaries for Linux and expect them to work on any distribution (I keep seeing this pattern and I guess it's because this typically works on macOS?). Moreover my distribution already has a package manager which can install Python. I get that some absolute niche cases might need this functionality, but that should most definitely be a separate tool. The problem isn't just that the functionality is in the same binary, but also that it can get triggered when you're using another of its functionalities. I wish this had been made into actual separate tools, where the useful ones can be adopted and the others ignored. And, most important, where the ecosystem can iterate on a single tool. Having "one tool that does 5 things" makes it really hard to iterate on a new tools that does only one of those things in a better way. It's pretty disappointing to see the Python ecosystem move in this direction.
- Balinares 11mo agoYour distro's package manager cannot install arbitrary versions of Python such as might be required by a specific Python project and it cannot install anything at all for individual users without root access. These are two different tools that serve two different purposes.
- pjmlp 11mo agoI never got why. I use Python since version 1.6, mainly for OS scripting, because I rather use something with JIT/AOT in the box for application software. Still, having a little setup script to change environment variables for PYTHONPATH, PATH and a few other things, always did the trick. Never got to spend hours tracking down problems caused by the multiple solutions that are supposed to solve Python's problems.
- gatvol 11mo agoUV is super fast and great for environment management, however it's not at all well suited to a containerised environment, unless I'm missing something fundamental (unless you like using an env in your container that is).
- __float 11mo agoWhy not use a virtualenv in your container?
- emeraldd 11mo agoThis is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.
- ghshephard 11mo agoI'm intrigued. I've been using virtualenv in numerous companies for about 8 years, traditionally wrapped in virtualenvwrappers, and now in uv. UV doesn't change any of that for me - it just wraps virtualenv and pip downloads dependencies (much, much) more quickly - the conversion was immediate and required zero changes. UV is a pip / virtualenv wrapper. And It's a phenomenal wrapper - absolutely changed everything about how I do development - but under the hood it's still just virtualenv + pip - nothing changed there. Can you expand on the pain you've experienced? Regarding "things that need to be deployed" - internally all our repos have standardized on direnv (and in some really advanced environments, nix + direnv, but direnv alone does the trick 90% of the time) - so you just "cd <somedir>", direnv executes your virtualenv and you are good to go. UV takes care of the pip work. Has eliminated 100% use of virtualenvwrappers and direct-calls to pip. I'd love to hear a use case where that doesn't work for you - we haven't tripped across it recently.
- torben-friis 11mo agoAs an outsider to python, I never got how a language who got popular for being simple, elegant and readable could end up with perhaps the most complex tooling situation (dependencies, envs, etc). Any time I glance at the community there seems to be a new way of doing things. What caused python to go through these issues? Is there any fundamental design flaw ?
- dgfitz 11mo agoPeople. People happened. Ideologies and strong opinions.
- lvl155 11mo agoI call it the JS-syndrome.
- javchz 11mo agoAs many flaws as the npm/yarn/pnpm ecosystem has, its interoperability is waaaay better than the whole juggling act between pip, ven, poetry, Anaconda, Miniforge, and uv across projects. UV it's a step in the right direction, but legacy projects without Dockerfile can be tricky to start.
- morshu9001 11mo agoJS did this right, in fact uv is kinda replicating the npm way. And there are other JS things I'd like Py to follow suit on.
- nomel 11mo agoSeems like the flaw is that it was never a first class citizen of the language. easy_install never even made it to 1.0 Still, not bad for a bunch of mostly unpaid volunteers.
- simonw 11mo agoIt's mostly about age. Python has been around for 35 years now. The first version of a Python package directory was the cheeseshop (Monthy Python reference) in 2003. The earliest version of a pip-like tool was "easy_install" which - I kid you not - worked by scraping the HTML listing page of the cheeseshop and downloading zip files linked from that! More recent languages like Node.js and Rust and Go all got to create their packaging ecosystems learning from the experiences of Perl and Python before them. There is one part of Python that I consider a design flaw when it comes to packaging: the sys.modules global dictionary means it's not at all easy in Python to install two versions of the same package at the same time. This makes it really tricky if you have dependency A and dependency B both of which themselves require different versions of dependency C.
- ThibWeb 11mo agoit’s my 1st attempt at reporting on CI downloads specifically. Interpreting this is more of an art than a science, I’d love to hear if others have ideas on what to do with this data!
- whalesalad 11mo agouv kinda drives me nuts with the hoops you have to go through to use a pre-existing virtual environment. it seems really keen on doing that itself.
- Alir3z4 11mo agoI seriously still don't know why I should use "uv". I just create my .venv and pip install. Rarely I'd need a different version of python, in case I do, either I let the IDE to take care of it or just do pyenv. I know there's the argument of being fast with uv, but most of the time, the actual downloading is the slowest part. I'm not sure how big a project should be, before I feel pip is slow for me. Currently, I have a project with around 50 direct dependencies and everything is installed in less than a min with a fresh venv and without pip cache. Also, if I ever, ever needed lock files stuff, I use pipx. Never needed the hash of the packages the way it's done in package-lock.json. Maybe, I'm just not the target audience of uv.
- babl-yc 11mo agoThere's a swarm on HN that upvotes anything uv related and downvotes anything questioning it's added value as compared to pip
- Alir3z4 11mo agoYes, that's a shame. I noticed the comment from andy99 got several downvotes (became grey) and mine here also immediately got some.
- zbentley 11mo agoI didn’t downvote you, but the “this tool is bad and if you take the time to argue with me you’re a Rust cultist” line is a bit tiresome. Damned if you do, damned if you don’t. It’s a bit like if anyone who said you should switch to desktop Linux got yelled at for being in the pocket of Big Systemd. “if you like it, use it” is well and good, but haranguing people who explain why they like/use what they use is just as lame as the purported cult defense of uv or whatever tool is popular. I dunno man, fads and stupid fixations happen in software sometimes, but most of the time hyped tools are hyped because they’re better.
- andy99 11mo agoIf it sold itself on its merits I don’t think we’d see all these fawning posts about it. It’s a Rust fan thing. You can see how any criticism gets treated. I’m sure it works for some people and obviously if it does, then great. But it’s got this same weird cult following and pretend talk of speed that lots of Rust stuff has. It’s getting a little tiring. If you like it, use it, evangelizing is obnoxious.
- markkitti 11mo agoIt sounds like there are many Python users who have acclimated to the situation of needing three or more tools to work with Python and do not see the benefit or value of being able to do this all with one potentially faster tool. While I understand that some have acclimated well to the prior situation and see no need to change their methods, is there really no objective self-awareness that perhaps having one fast tool over many tools may be objectively better?
- JoBrad 11mo agoThe Astral team did a great job with uv (and ruff!). I just wish they had used `install` instead of `add` and `sync`. `uv install` = `uv sync` `uv install rich` = `uv add rich`
- wishitwerentso 11mo agoIt makes using python tolerable. Thank you Rust and the Astral team!
- rednafi 11mo agoI literally stopped writing Python for scripting a year ago - the distribution story was too painful. With LLMs, there's not much a dynamic language offers over something like Go even for quick scripting. Also, on a new machine, I could never remember how to install the latest version of Python without fiddling for a while. uv solves the problem of both installation and distribution. So executing `uv run script.py` is kind of delightful now.
- aaronbrethorst 11mo agoI'm stuck on poetry until Snyk adds support for uv. Ugh. If anyone from Snyk is reading this, please go yell at whoever Jacob is: https://support.snyk.io/s/question/0D5PU00000u1G4n0AE/support-for-uv-as-a-package-manager-for-python https://support.snyk.io/s/question/0D5PU00000u1G4n0AE/suppor...
- bkettle 11mo agoSemgrep has supported uv for months now (I added it).
- deleted 11mo ago[deleted]
- ai-christianson 11mo agoSimple: uv run script.py just works on a clean box/CI, the lockfile keeps runs reproducible, and my CI “install deps” step is way faster now.
- NSPG911 11mo agouv still has some issues, it cannot pull from global installations like pip, so on termux, something like tree sitter cannot be installed, because tree sitter is provided by apt/pkg
- 0xpgm 11mo agoStill waiting to see how the VC-funded company behind Uv will make money. Before that, I wouldn't want to be too dependent on it.
- make3 11mo agohuggingface scares me in that regards
- drcongo 11mo agoThis is all publicly available if you look.
- mixmastamyk 11mo agoUv and ruff are near feature complete and open source. It's very likely they'll survive in one way or the other and are already better than the tools they're meant to replace.
- 112233 11mo agoI'm at the point where I don't touch python without uv at all, if possible. The only bad is, now I want to use uv to install go and java and debian packages too ... :( The ability to get random github project working without messing with system is finally making python not scary to use.
- icar 11mo agoYou might be interested in mise [0]: mise use -g go@1.24 mise use -g java@latest mise use -g github:BurntSushi/ripgrep [0]: https://mise.jdx.dev/ https://mise.jdx.dev/
- 112233 11mo agoThis looks .. epic. How comes it has flown under my radar, feels like finding gnome village in your car glovebox. Thank you for the mention!
- droelf 11mo agoPixi works for this use case: https://pixi.sh/latest/ https://pixi.sh/latest/ It gives you cross-platform binary packages, quickly (also written in Rust).
- adfm 11mo agoInteresting to see Wagtail mentioned on HN. Anyone using it in production care to chime in on how uv improves your experience?
- drcongo 11mo agoWe use Wagtail with uv all the time - uv is just better at every single thing it does than any other way of doing any of those things.