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.
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?
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
The above is from memory typed on a phone so maybe some minor syntax issues but the point i tried to make was we can kinda emulate the convenience of statically compiled binaries a-la Go these days
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.
What people like about this workflow is that you're not maintaining a separate venv or a separate requirement and it's declarative rather than imperative, this gives you two big advantages:
First, you can move that script to a different machine and do `uv run {script}`, no need to recreate a venv or provide install instructions (I believe uv will now even grab an appropriate version of Python if you don't have it?). This comes from PEP 723, and multiple tools support doing this, such as hatch.
Second, when you "add" a requirement instead of "install" a requirement it manages that with the knowledge of all requirements that were added before. For example, if I `pip install foo` and then `pip install bar` pip does not consider foo or it's dependencies as required when installing bar, so it's possible that you can break `foo` by installing completely incompatible dependencies. But when you "add foo" and then "add bar" from uv (and other tools that are declarative, like Poetry) your environment gets updated to take everything into account.
If managing Python dependencies is second nature to you then these might seem like extra concepts to keep in your head, but lots of people do find these useful because they find they can think less about Python dependencies.
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?
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!)
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.
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?
They don’t. That’s a sign that the local system is severely broken, and should be rebuilt to be stable. uv will still work in that case, but you’re going to constantly hit other points of friction on a mismanaged system which will waste time.
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.
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.
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/.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
What a great thing to see on HackerNews this morning. Any day I can replace another tool in my team’s processes with a fast, stable, and secure solution from Astral is a great day. Thanks Astral for all the amazing work you do!
So if you've imported pytest and want to run it, you can’t just «uv run pytes», but have to create a script with a uv-shebang which runs pytest for you?
And how does that work on Windows, which to my knowledge doesn’t even support shebangs?
There's rather too many gleeful exclamation marks. Here's a rare case where a karmascope would be useful; I see https://news.ycombinator.com/user?id=the_mitsuhiko has 15025 karma, so they're almost certainly real.
Interesting that this was pushed to the bottom of the replies (despite being at the top at 20 upvotes). Did all the above comments get a coordinated signal to upvote beyond that number, or is a HN mod compromised?
Building tooling in Rust? Blasphemy! You should have used Node.js, because teaching Rust to people is too hard! And it's not doing any CPU heavy computations anyway, so Node.js is fine!
I wouldn't be so sure about spelling mistakes. Even before LLMs, YouTube bots made a lot of mistakes (probably because gives the impression that it's a human typing). Currently, it's impossible to distinguish between a human and LLM comment.
I'm continuing to be amaxed at the astral team and what they do for Python. It's become so "bad" now that when I use Rust or OCaml I find myself constantly annoyed by the build systems. What a great time to be alive!
What does uv do that Cargo does not? Cargo has been excellent in my experience, to the point that (in comparison to CMake and wanting to flee it) it is a large part of why I initially learned Rust.
Just the git code according to their'd README.md, however it seems heavily influenced by it.
Before uv I was doing everything in a devcontainer on my Mac since that was easiest, but uv is super fast that I skip that unless I have some native libraries that I need for Linux.
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.
using uv after years of fumbling with pip/venv, pyenv, conda, etc feels like a superpower. It really just works.
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.
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?
It's not rivaling Go anytime soon but there have been leaps and bounds.
E.g.
Then on another machine: The above is from memory typed on a phone so maybe some minor syntax issues but the point i tried to make was we can kinda emulate the convenience of statically compiled binaries a-la Go these daysI 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.
Compare the before vs after
Before (analogous to go mod init):
On another machine (still the before scenario, this time analogous to maybe go run): In the after scenario: That's it. Comparable toWhat people like about this workflow is that you're not maintaining a separate venv or a separate requirement and it's declarative rather than imperative, this gives you two big advantages:
First, you can move that script to a different machine and do `uv run {script}`, no need to recreate a venv or provide install instructions (I believe uv will now even grab an appropriate version of Python if you don't have it?). This comes from PEP 723, and multiple tools support doing this, such as hatch.
Second, when you "add" a requirement instead of "install" a requirement it manages that with the knowledge of all requirements that were added before. For example, if I `pip install foo` and then `pip install bar` pip does not consider foo or it's dependencies as required when installing bar, so it's possible that you can break `foo` by installing completely incompatible dependencies. But when you "add foo" and then "add bar" from uv (and other tools that are declarative, like Poetry) your environment gets updated to take everything into account.
If managing Python dependencies is second nature to you then these might seem like extra concepts to keep in your head, but lots of people do find these useful because they find they can think less about Python dependencies.
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?
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!)
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.
Another great milestone in an awesome suite of python tools. UV got me using virtual environments again. I especially love it in CI/CD.
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.
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.
I think hatchling or setuptools are still better options (for now). Would be great to see a clean, declarative hook system in the future
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?
> how do people work like this?
They don’t. That’s a sign that the local system is severely broken, and should be rebuilt to be stable. uv will still work in that case, but you’re going to constantly hit other points of friction on a mismanaged system which will waste time.
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.
They use uv.
The linked URL doesn't really explain, what does "stable" mean here?
It was marked as experimental earlier on, the docs linked are the stable version + how to use it.
The admonition at the top:
makes it seem like it's not yet stable, or at least feels like they're still not encouraging it.I'm quoting Charlie, the creator of uv https://bsky.app/profile/crmarsh.com/post/3lszmqo27b224
Ah, great. Thanks for the reference.
My pleasure!
We consider it a breaking change to switch the default, so that's coming a bit later.
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.
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/.
They do provide official solutions. The problem is the official solution keeps changing.
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.
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?
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.
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.
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.
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.
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.
konsti from Astral tells me they do not support manylinux yet, only pure python. https://github.com/pypa/manylinux
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.
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.
[1] https://news.ycombinator.com/item?id=44358482
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.
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.
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.
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.
What a great thing to see on HackerNews this morning. Any day I can replace another tool in my team’s processes with a fast, stable, and secure solution from Astral is a great day. Thanks Astral for all the amazing work you do!
uv and ruff are the two best things to happen to Python in the 15 years I've been writing it. Everyone at Astral, I owe you a beer.
So, this puts the Python runtime on Node.js' battle-proven libuv?
The comments in this thread all feel like auto generated engagement bot replies you'd see on twitter.
I know ! the problem is that when a product is so good that it converts people into evangelicals about it
With that said — it’s uv or die for me
I’ve been using and advocating uv ever since forever. It’s impossible to think about using python without nowadays.
Among many things it’s improved, scripting with python finally just works without the pain of some odd env issue.
> Among many things it’s improved, scripting with python finally just works without the pain of some odd env issue.
From what I can tell uv doesn’t (unlike poetry) assist with venvs what so ever.
What is a trivial «poetry run» becomes the same venv-horrors of Python fame when I use uv and «uv run».
Based on that, your comment strikes me as the polar opposite of my experience (which is why I still resort to poetry).
Care to outline how you use v to solve venv-issues, since from what I can tell, uv explicitly doesn’t?
I’m very curious.
I use uv in my shebang and “uv run script.py”. Never run into any issues.
Here’s a couple links to discussions about it on HN:
https://news.ycombinator.com/item?id=42198256
https://news.ycombinator.com/item?id=42855258
So if you've imported pytest and want to run it, you can’t just «uv run pytes», but have to create a script with a uv-shebang which runs pytest for you?
And how does that work on Windows, which to my knowledge doesn’t even support shebangs?
There's rather too many gleeful exclamation marks. Here's a rare case where a karmascope would be useful; I see https://news.ycombinator.com/user?id=the_mitsuhiko has 15025 karma, so they're almost certainly real.
I'd think the same, but I agree with all the comments.
Interesting that this was pushed to the bottom of the replies (despite being at the top at 20 upvotes). Did all the above comments get a coordinated signal to upvote beyond that number, or is a HN mod compromised?
Building tooling in Rust? Blasphemy! You should have used Node.js, because teaching Rust to people is too hard! And it's not doing any CPU heavy computations anyway, so Node.js is fine!
unlike ruff, uv doesnt benefit that much from being written in rust.
its main benefit is that it is well maintained and does everything you used to need a string of tools for before.
Oh that's so very false!
---
time uv
real 0m0.005s
user 0m0.000s
sys 0m0.004s
---
time npm
real 0m0.082s
user 0m0.068s
sys 0m0.020s
---
time pip
real 0m0.320s
user 0m0.179s
sys 0m0.031s
lol i dont think people are switching because they save 255 milliseconds per command line run.
No. You must rewrite it in Zig. Or C like a real man. Or if you're Chuck Norris just look at computer angrily.
[dead]
Bots don't make that much spelling mistakes. Bots as in LLMs not people paid to engage.
My good uv experience. I tried installing tensor/cuda Python code recently. Plain pip just failed. uv pip actually returned WHY it failed.
It definitely felt like magic.
I wouldn't be so sure about spelling mistakes. Even before LLMs, YouTube bots made a lot of mistakes (probably because gives the impression that it's a human typing). Currently, it's impossible to distinguish between a human and LLM comment.
>Bots don't make that much spelling mistakes.
They do if you instruct them to.
Why would you want them to make spelling errors? The benefits don't outweigh the costs.
donkey_brains definitely looks to have low karma, the rest of the comments seem legit.
I'm continuing to be amaxed at the astral team and what they do for Python. It's become so "bad" now that when I use Rust or OCaml I find myself constantly annoyed by the build systems. What a great time to be alive!
What does uv do that Cargo does not? Cargo has been excellent in my experience, to the point that (in comparison to CMake and wanting to flee it) it is a large part of why I initially learned Rust.
Really? So far I have never been disappointed with Cargo, or the Rust toolchain in general. For my work it has been a frictionless experience.
I really like cargo and uv. I assumed uv was based on cargo...
Just the git code according to their'd README.md, however it seems heavily influenced by it.
Before uv I was doing everything in a devcontainer on my Mac since that was easiest, but uv is super fast that I skip that unless I have some native libraries that I need for Linux.