Uv, a fast Python package and project manager

Someone needs to collect the data on UV&#x27;s rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. Between this and other tooling from that same company, it feels to me that, in the space of less than a year, Python has turned from a community language into a company-led one (like. e.g. Scala).<p>Not saying whether it&#x27;s good or bad - just that it&#x27;s damn curious how this played out. It feels like Python leadership got taken over by some company almost overnight; I&#x27;d love to understand how did this happen.<p>--<p>[0] - Arguably an outsider to Python community, but like everyone else, downstream of it, and always affected by it, ever since Python became the de-facto standard in Linux as the language between C and Bash.<p>[1] - Anyone remembers <i>libuv</i>? Spearheading the whole async&#x2F;await paradigm by powering it in Node.JS, it&#x27;s one of the most known and talked about libraries ever.

Uv has been awesome so far. It brought the release time for Home Assistant down from an hour and a half to about 15 minutes.<p>Also installing all the dependencies from scratch used to give you enough time to grab lunch and drink coffee, and now we can only grab the coffee in that time!

Things i love about uv&#x2F;astral<p>- Putting .venv automatically into the project directory<p>- Installing dependencies with pyproject.toml<p>- Installing any Python version<p>- Fast pip installs<p>- uvx (like npx)<p>- Ruff formatter and linter, made by the same people<p>Python used to give me a headache, now I tend to reach for it more often, exclusively thanks to uv

If I was the Python BDFL I would just merge this into pip and solve Python packaging forever. Only decisive action will fix package tooling fragmentation.

Have they figured out yet how this VC backed company will make money? It&#x27;s quite important imo, I don&#x27;t want a watered down experience 5 years from now.

For me it is not great because of the new requirement for &quot;rust&quot; for basic Python. Does not make any sense.<p>Especially if the main selling point is &quot;speed&quot;. I never encounter cases where the pip install equivalent was particularly unbearably long except in very badly designed and broken projects. The kind of one that that import every possible dependency (nom style) with pinning things on broken and incompatible set of dependencies...<p>Also, I like very much the concept of one tool for one usage. And having venv and pip is great, having one tool cluster mixing everything is not. Sure in most dummy usage cases it will be great, but you have more chance of clusterfucks and complicated unresolvable issues. Even more if developers are opinionated on a single way to do something.

Using `uv` for Python is the first time I have used Python and enjoyed the experience full stop.<p>`ruff` is also just straight up amazing.<p>Everything else should do us all a favor and deprecate itself tomorrow.

I’ve been missing a python tool like this that isn’t written in python. Conda was good in this regard - having a distribution without first installing python is a massive improvement to the «getting started» problems in python.

Not quite sure what kind of projects people are talking about here, where Poetry takes too long. Must be pretty massive sets of dependencies. Maybe huuuge monoliths? What I usually do is build a venv in a docker container of a service and then that gets deployed. I don&#x27;t see a problem, if this took a minute or two, but so far it never did take that long.

The answer to the question about VC funding is weirdly obvious at any sort of distance away from the emotive things.<p>Communities should probably cautiously welcome VC funding for well-integrated community members solving hard, core problems with correctly-licensed contributions back to the community, as long as that effort doesn&#x27;t divert community engineering focus away from long-term community goals and towards the startup&#x27;s goals in non-beneficial way.<p>They should be more cynical about things that don&#x27;t happen this way, but then they can keep doing their own thing anyway.<p>Ondsel found the money for two major core technical problems to be addressed in FreeCAD, and seems to have had a pretty positive impact on release-oriented thinking in general. They then folded. It is a loss, but essentially none of the work was lost.<p>Frankly I am not sure if the &quot;written in Rust&quot; element here is culturally beneficial in the long term or not; I don&#x27;t know enough about Python or really anything about Rust.

Please give me commands to create a virtual environment built with libraries listed in the requirements.txt of a GitHub repo.<p>Ubuntu here.

Happy user so far in my early days ... appreciate the speed for sure

So, why should I switch to this and what is going to stop some other tool becoming the &quot;python package&#x2F;env management darling&quot; in 2025?

I have noticed a spike in attention to UV since Anthropic announced the Model Context Protocol (MCP). After using it for MCP development, I am moving from pyenv to uv! <a href="https:&#x2F;&#x2F;www.anthropic.com&#x2F;news&#x2F;model-context-protocol" rel="nofollow">https:&#x2F;&#x2F;www.anthropic.com&#x2F;news&#x2F;model-context-protocol</a>

Super fast installs - when it works. I had problems on Ubuntu for linux (WSL) with a clang dependency, which i could never solve. But on linux boxes, it&#x27;s so much better than pip&#x2F;conda&#x2F;etc.<p>I also like that i can use it with conda environments. Just create conda env, then install with &#x27;uv pip install ....&#x27;

I have only ever really used venv. Poetry was fine but didn&#x27;t give me any additional benefits that I could see. What does this offer? And more broadly, why do people consider pip to be a problem? I have literally never had any issues with it in any of my projects.

Is there any way to make wheels with pinned dependencies with this?<p>That&#x27;s the main thing keeping me with Poetry.<p>Other than that I&#x27;m super excited.

Does this still work if other devs on the project still use pyenv or other tools ?

&gt; poetry: 0.99 seconds<p>Good enough for me and sans VC risk.

Honestly? It&#x27;s excellent but it&#x27;s Python only, I dream a day where NixOS&#x2F;Guix Systems will be so common that anybody will use their approach to develop in any language (and the future Nix is something more digestible and Guix system will care more about the desktop, as side dreams)...

uv is cool, no doubt—super fast, love the idea of managing Python versions + deps all in one place. But VC funding... Rust... unofficial Python builds... lots of red flags here if you think about the long-term impact on the ecosystem.<p>VC-backed tools always make me a little nervous. Sure, Astral says the tools will stay free, and I get that they&#x27;re targeting enterprise for revenue (private package registries, etc.). But how many times have we heard this before? “Don’t be evil,” right? We’ve seen companies pivot to paywalls or watered-down open-source tools after funding dries up. What guarantees do we have here that uv won&#x27;t eventually fall into that same trap?<p>Yeah, Rust is amazing (ruff is a beast), but it’s still a small subset of devs compared to Python. If Astral folds or just loses interest, how easy is this really going to be for the Python community to maintain? Forkable? Sure. But forkable ≠ maintainable when the dev pool is tiny.<p>Also, what&#x27;s with using unofficial Python builds by default? Even on platforms where official builds exist (macOS&#x2F;Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave &quot;uv&quot;? Why not at least give users the option to rely on official binaries?<p>And fragmentation... Python tooling is already a mess. Pip, poetry, conda, pyenv, rye, flit, etc.—do we really need another tool in the mix? Feels like every new tool just promises to &quot;fix packaging forever&quot; but ends up adding another layer of complexity. Why not contribute these improvements to existing tools like pip? Sure, innovation is great, but at what point does it become too much choice and not enough cohesion?<p>uv looks great, and I love the speed + features. But the ecosystem-level risks here... hard to ignore. Would love to see some stronger guarantees around open-source sustainability, community governance, and alignment with Python standards before jumping in fully. Otherwise, it’s just one more shiny tool that could end up abandoned or locked behind a paywall in 5 years.

Since the topic of VC funding keeps coming up, I will quote myself from the blog post I did a few months ago [1]:<p>&gt; there is an elephant in the room which is that Astral is a VC funded company. What does that mean for the future of these tools? Here is my take on this: for the community having someone pour money into it can create some challenges. For the PSF and the core Python project this is something that should be considered. However having seen the code and what uv is doing, even in the worst possible future this is a very forkable and maintainable thing. I believe that even in case Astral shuts down or were to do something incredibly dodgy licensing wise, the community would be better off than before uv existed.<p>[1]: <a href="https:&#x2F;&#x2F;lucumr.pocoo.org&#x2F;2024&#x2F;8&#x2F;21&#x2F;harvest-season&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lucumr.pocoo.org&#x2F;2024&#x2F;8&#x2F;21&#x2F;harvest-season&#x2F;</a>

UV creator&#x27;s response on the concerns regarding VC money:<p>&gt; I don&#x27;t want to charge people money to use our tools, and I don&#x27;t want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models).<p>&gt; What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today.<p>&gt; An example of what this might look like (we may not do this, but it&#x27;s helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...]<p>&gt; But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they&#x27;re already using our OSS.<p><a href="https:&#x2F;&#x2F;hachyderm.io&#x2F;@charliermarsh&#x2F;113103564055291456" rel="nofollow">https:&#x2F;&#x2F;hachyderm.io&#x2F;@charliermarsh&#x2F;113103564055291456</a>

A VC-funded package and project manager for Python projects, written in Rust, and without involvement of the Python Packaging Authority (PyPA). If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether?<p>Using Rust enables uv to install Python interpreters. That feature uses unofficial third-party binary builds. There are no official binary builds for Linux, but there are such builds for Windows and macOS, yet they use the unofficial third-party builds on those platforms as well. Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool (which may be the system package manager on some platforms).

Pixi is just better.