The uv build back end is now stable
71 comments
·July 3, 2025the_mitsuhiko
sambaumann
using uv after years of fumbling with pip/venv, pyenv, conda, etc feels like a superpower. It really just works.
lioeters
Even as an occasional casual Python user of several years, I noticed how much simpler it is to check out new projects using uv compared to other tools. It's such a relief because I used to encounter so many weird compatibility issues with Python, I guess mostly related to global installs of runtime versions and dependencies. In the past year or so, the situation seems to have dramatically improved thanks to uv.
TechDebtDevin
Interesting. I basically dont touch python unless I have too becayse the lack of tooling. How does this tooling compare to an experience like working in Go?
CraigJPerry
It's not rivaling Go anytime soon but there have been leaps and bounds.
E.g.
uv init --script foo.py
uv add --script foo.py httpx
cat foo.py
...
dependencies = ['httpx']
...
uv run foo.py
# creates a virtual env, reads foo.py to see httpx is a dependency, installs in the ephemeral venv then runs the script
cssanchez
I don't mean to be rude, but I don't get how this is any better. Feels too manual to type "uv -add dep script.py" instead, I feel the automation tool I'm waiting for will scan my script, auto-import all the deps I'm calling in the script while ignoring the ones that I forget to use, AND set up the env with all the deps AND run the code in the same one liner. To me, uv add X is no different than running env/pip install requirements.txt.
tajd
I really like using UV. I introduced it at work for builds and it made everything a lot faster which was awesome. Now I can remove the other components of the build process and just use one.
I am interested in how they're going to make money eventually, but right now it's working for me.
Does anyone have an idea about how they're going to monetize?
djinnish
I feel like that's the biggest question I have about Astral. I wonder what they have in the tank. All of this software is great, but I'd like to see them get some kind of benefit, if only to assure me that they'll continue to exist and make awesome software.
(And also so they'll implement the `pip download` functionality I'd like!)
StackTopherFlow
Huge thank you for all the amazing work the astral team is doing. uv is an absolute game changer and I can’t imagine going back to a pre-uv world.
RGBCube
Total distribution packager win!
Will it support the wide range of options setuptools does? Or maybe a build.rs equivalent - build.py, but in a sane way unlike setup.py.
notatallshaw
Astral's focus has been to support the simplest use case, pure Python project with a standard layout. Their aim has been that most users, and especially beginners, should be able to use it with zero configuration.
As such they do not currently support C extensions, nor running arbitrary code during the build process. I imagine they will add features slowly over time, but with the continued philosophy of the simple and common cases should be zero configuration.
For Python experts who don't have special needs from a build backend I would recommend flit_core, simplest and most stable build backend, or hatching, very stable and with lots of features. While uv_build is great, it does mean that users building (but not installing) your project need to be able to run native code, rather than pure Python. But this is a pretty small edge case that for most people it won't be an issue.
fossa1
I think hatchling or setuptools are still better options (for now). Would be great to see a clean, declarative hook system in the future
h1fra
I tried installing a Python project last week after years of avoiding it like the plague. brew install didn't work, use python3 not python, no pip pre-installed, ensurepip is crashing, you need to run sudo commands to fix this, after 1hour of struggle, repo didn't work anyway. how do people work like this?
NeutralForest
You can just use uv now, that's the whole point, it will let you install any recent version of python and you can easily handle it from there. It'll also handle dependencies and one-off scripts for which you don't want to create a whole project/venv.
By rule, you should never meddle with the globally installed python because so many packages will try to look for the system installed Python and use it, better let your package manager handle it.
makeworld
They use uv.
mkj
The linked URL doesn't really explain, what does "stable" mean here?
NeutralForest
It was marked as experimental earlier on, the docs linked are the stable version + how to use it.
milliams
The admonition at the top:
Currently, the default build backend for uv init is hatchling. This will change to uv in a future version.
NeutralForest
I'm quoting Charlie, the creator of uv https://bsky.app/profile/crmarsh.com/post/3lszmqo27b224
zanie
We consider it a breaking change to switch the default, so that's coming a bit later.
null
blahgeek
I've been coding in Python for 10+ years but I can never really get python's tooling ecosystem. It seems that there's always a newer shiny choice. easy_install, pip, conda, virtualenv, pipenv, setup_tools, hatchling, setuptools-scm, uv, requirements.txt, pyproject.toml...
I wish python can provide an "official" solution to each problem (like in rust, there's cargo, end of story), or at lease, an official document describing the current best practice to do things.
tdhopper
I'm not sure you'll get official documentation beyond the PPUG (https://packaging.python.org/en/latest/) which, for reasons, doesn't even mention uv.
For the last year or so, I've been trying to provide an alternative guide that stays abreast the best options and provides simple guides: https://pydevtools.com/.
twixfel
They do provide official solutions. The problem is the official solution keeps changing.
bgwalter
People have been asking how Astral is going to monetize. Given the "AI" posts from Astral adjacent people, I'm now considering that they might release "AI" tools for an integrated "developing" workflow.
loks0n
Feels like Astral are going to eat the whole python eventually.
Makes me wonder, did the Python core team fail to see the opportunity in python tooling, have no desire to build it, or they didn't have the skills?
pjc50
The python team build python. I suspect that insulates them from the actual problems of trying to build things with python. Also this sort of thing gets bogged down in approval processes. People have spent decades trying to "fix" python packaging; the important thing is that uv doesn't change any of that, it's a drop in replacement.
troyvit
Yeah it reminds me of bun, for node, in that way (and that probably exposes how well I understand tooling). It's like somebody just swept everything off the table and started over.
I never learned python the way I wanted to because for years I would first look at the excruciating transition from v2 to v3 and just not see a point of entry for a newb like me.
Now the same thing is happening with tooling for v3. pip? pepenv? python pip? python3 pip? I don't freakin' know. Now there's uv, and I'm kinda excited to try again.
NeutralForest
If you take a look at the forum (https://discuss.python.org/), the core team basically doesn't have the resources to do anything else expect maintaining Python. They aren't paid and have to pick their battles.
They spend a lot of time on improving Python itself and then you have pip which is a way to install packages and that's it; it's not a package manager nor a python version manager.
bgwalter
To be fair here, the recent PEPs encourage external build back ends (which this submission is about).
That said, the people left in the CPython team generally have a low regard for bloat-free, correct and fast solutions, so external solutions are most welcome.
oceansky
Rewriting proven working tools from scratch has the benefit of knowing the pain points, but it also a huge chore that may break a lot of things.
I don't blame the core python team for not super optimizing tools like Astral.
esafak
konsti from Astral tells me they do not support manylinux yet, only pure python. https://github.com/pypa/manylinux
Slippery_John
uv has a super power that it doesn't much talk about - seamlessly managing monorepos. I'd been using pants before, but it's such a pain to setup and maintain. uv just kinda works like you'd hope.
ewalk153
I was looking for Astral’s future plans to make money. Simonw already answered in another post [1] tldr - keep tooling open and free forever, build enterprise services (like a private package registry) on top.
dashdotme
Good thing to highlight. I'm not sure I'd bet on the game plan, but uv is an incredibly useful tool which I also wouldn't have bet on. Hopefully Simonw is right, and Astral can maintain as is.
pydry
the fact that there are 3 "hopefullys" in the paragraph that explains the strategy doesnt inspire much confidence.
I dont think there is enough money in package registries to pay for all of the VC investment in astral.
tecleandor
Well, that's basically the core of Anaconda, and it's working for them.
That said, I've checked Anaconda's site, and while it used to be "Anaconda [Python] Commercial Distribution", "On-Prem repositories", "Cloud notebooks and training"... during the last year they've changed their product name to "Anaconda AI Platform", and all it's about "The operating system for AI", "Tools for the Complete AI Lifecycle". Eeeeh, no thanks.
pydry
not sure i hold out much long term hope for them either. both of these companies can eventually make money in a way that isnt shady - just not enough money to satisfy their VCs.
Turns out you can just do things. The astral tooling is by far the best thing that has happened to Python in years and it makes me very happy.