Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions.

Maybe you could. I would stare longingly into the void, wondering if I can ever work another python project after having experienced uv, ruff, and ty.

Such an outcome would make me wonder regarding the wisdom of "It is better to have love and lost than to have never loved at all."

I was using poetry pretty happily before uv came along. I’d probably go back.

Note that uv is fast because — yes, Rust, but also because it doesn’t have to handle a lot of legacy that pip does[1], and some smart language independent design choices.

If uv became unavailable, it’d suck but the world would move on.

[1] https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Maybe I could give up uv, but giving up ruff would suck.

This is just the weirdest thread.

Like, the whole point of open source is that this thread is not a thing. The whole point is "if this software is taken on by a malevolent dictator for life, we'll just fork it and keep going with our own thing." Or like if I'm evaluating whether to open-source stuff at a startup, the question is "if this startup fails to get funding and we have to close up shop, do I want the team to still have access to these tools at my next gig?" -- there are other reasons it might be in the company's interests, like getting free feature development or hiring better devs, but that's the main reason it'd be in the employees' best interests to want to contribute to an open-source legacy rather than keep everything proprietary.

The leadership and product direction work are at least as hard as the code work. Astral/uv has absolutely proven this, otherwise Python wouldn't be a boneyard for build tools.

Projects - including forks - fail all the time because the leadership/product direction on a project goes missing despite the tech still being viable, which is why people are concerned about these people being locked up inside OpenAI. Successfully forking is much easier said than done.

I had a lot of trouble convincing people that a correct Python package manager was even possible. uv proved it was possible and won people over with speed.

I had a sketched out design for a correct package manager in 2018 but when I talked to people about it I couldn't get any interest in it. I think the brilliant idea that uv had that I missed was that it can't be written in Python because if is written in Python developers are going to corrupt its environment sooner or later and you lose your correctness.

I think that now that people are used to uv it won't be that hard to develop a competitor and get people to switch.

Ruff is performant but finds about half the issues Pylint does (see https://github.com/astral-sh/ruff/issues/970). Ty is quantitatively the worst of the well-known type checkers (see https://news.ycombinator.com/item?id=47398023). Uv is Astral's only winner.

You are aware that ty has only recently entered beta status?

Ruff isn’t stable yet either and has evolved into the de facto standard for new projects. It has more than double the amount of rules than Pylint does. Also downloaded more than 3 times as often as Pylint in the past month.

Pylint has some advantages, sure, but Ruffs adoption speaks for itself. Pylint is 25 years old. You’d hope they do some things better.

Saying that uv is their only winner is a hilarious take.

>Saying that uv is their only winner is a hilarious take.

na this news is good enough reason to move from Ruff back to black and stay the course, I won't use anything else from Astral. I will use uv but only until pip 2/++ gets its shit together and catches up and hopefully then as a community we should jump back on board and keep using pip even if it's not as good, it's free in the freedom sense.

Reread the comment I replied to:

> I would stare longingly into the void, wondering if I can ever work another python project after having experienced uv, ruff, and ty.

You think you're disagreeing with me, but you're agreeing. To wit: The original post is silly, because ty is beta quality and Ruff isn't stable yet either. Your words.

These are just tools, Pylint included. Use them, don't use then, make them your whole personality to the point that you feel compelled to defend them when someone on the Internet points out their flaws. Whatever churns your butter.

It is an MIT licensed project, someone will absolutely fork it.

You seem to be underestestimating the laziness of the people, and overestimating their resolve. Angry forks usually don't last, angst doesn't prevent maintenance burnouts.

clicking "fork" in github is pretty easy

If you think clicking “fork” is all there is to it, I have some bad news for you.

You underestimate the value that something like uv and company bring to the ecosystem. Given enough time I could have seen it replacing some core utilities, now that its owned by OpenAI I don't see that happening, unless OpenAI "donates" the project but keeps the devs on a payroll.

Maybe consider something other than python.

Always choose the best tool for the job.

Then import that tool and and check if __name__ == "__main__"

Good luck with that. I haven't been successful at convincing anyone to move away from it. I'm so fucking sick of writing Python at work lol

Why?

Because I hate dynamically typed languages for anything besides scripting and glue code.

Or are you asking why I haven't had success? Mostly because the people I work with are dead set that Python is perfect for everything. I had one guy argue it should be used for embedded work

What would you prefer to use?

Just about anything, as long as it's statically typed.

The domain I work in is basically perfect for Go, so I've been pushing for that.

Eurgh, I do not want to ever touch Poetry or pyenv again, thank you very much.

While I hope it never comes to that, all the code is MIT licensed, I would assume everyone would make the sensible decision for fork it.

I see Apache and MIT license files in their GitHub. What's to prevent the community from forking and continuing development if the licenses change?

The same things that prevented "community" from building the tool in the first place

i think the main problem was that people didn't believe that pip was broken, or didn't think there was any value in a 100% correct package manager over a 97% correct package manager (e.g. misread "worse is better")

I had the problem basically understood in 2018 and I am still pissed that everybody wanted to keep taking their chances with pip just like they like to gamble with agent coders today.

Now that people know a decent package manager is possible in Python I think there is going to be no problem getting people to maintain one.

Idk how anyone could sustain the impression that pip was not broken unless they had basically never used anything else (including Linux package managers) long enough to have even a basic understanding of it.

And that's a big part of what's so frustrating about Python generally: it seems to be a language used by lots of people who've never used anything else and have an attitude like "why would I ever try anything else"?

Python has a culture where nominal values of user-friendliness, pragmatism, and simplicity often turn into plain old philistinism.

I had a breakthrough moment when someone at a workplace (software dev) said something about a thing that wasn't working on their device. Their language made it clear to me that they didn't know how to troubleshoot to figure out how to fix it. But they could write software that ran on millions of devices. Ok, that made me take a step back.

In the early 2000s I was in a rough patch in my career and wound up working at a small town web design shop that had done a lot of really amazing work, like a line of business system for car dealers, an e-commerce site for vineyards, a custom CRM for an academic department, etc. Nobody there knew about version control (not so weird in 2005) or how to write joins in SQL.

that makes zero sense to me. developing something like ruff from scratch takes a lot of things happening - someone having the idea, the time to develop it from scratch in their free time, or the money to do it as a job, and perhaps the need to find collaborators if it's too large a project for one person. but now ruff is there, there's no need to build it from scratch. if I wanted to build a python linter or formatter I would simply fork ruff and build on top of it. as others have said in this subthread, that's the whole point of open source!

> the time to develop it [not] from scratch in their free time, or the money...

How do you think the magic of open source resolves this issue? Think about this for it to make some sense

> I would simply fork

The only simple part here is pressing the "fork" button, which only gives you exactly the same code that already exists, without user awareness or distribution

you're moving the goalposts now. I never said it would be easy to get used awareness or adoption, just that it would be a lot easier to write a new linter by forking and continuing ruff development than it would doing so from scratch.

as to how the magic of open source resolves the time and money issue, it literally gives you the building blocks you need to not have to invent everything from scratch. how is that not significant?

> just that it would be a lot easier to write a new linter by forking

And I never said about the relative ease, you've moved the goalpost there yourself. $1m required to maintain is much less than $10m required to create, yet when you don't have $1m it doesn't matter - you'll still fail, and reasons are the same as the reasons you couldn't build the original.

Blocks lying around does not a building make, so you haven't addressed that magic either.

it does not take $1M to maintain a linter, these tools can and have been built and maintained by people in their spare time. astral built a better one, for which I am genuinely grateful to them, but it's not like they invented linting or that the open source community was just waiting around for some business to supply their tooling. indeed developer tools are notoriously hard to make money off simply because so many good ones have been developed as either solo or community open source projects, largely by people in their free time.

Cannot we at one point consider the tool to be "done"? I mean, what is there to constantly change and improve? Genuinely curious. It sounds like a tool that can be finished. Can it not be?

You’d be surprised how many features the Python runtime adds each release. It’s not trivial for tooling to keep up with language changes.

So why isn't pip done?

I mean, if you believe the hype on this website, Claude Code could build a perfect clone of uv in a few hours using only the documentation.

Ruff is nice, but not important, uv is one of the few things making the python ecosystem bearable. Python is a language for monkeys, and if you don't give monkeys good tools, they will forever entangle themselves and you. It is all garbage wrapped in garbage. At least let me deploy it without having to manually detangle all that garbage by version.

I'm done pretending this is a "right tools for the right job" kind of thing, there's wrong people in the right job, and they only know python. If no one self-writes code anymore anyway, at least use a language that isn't a clusterfuck of bad design decisions, and has 1 trillion lines of code in the collective memory of people who don't know what a stack is.

> If no one self-writes code anymore anyway, at least use a language that isn't a clusterfuck of bad design decisions

I can get behind the idea that LLM's probably don't need a language designed for humans if humans arent writing it, but the rest of this is just daft. Pythons popularity isn't just pure luck, in fact its only been in recent years that the tooling has caught up to the point where its as easy to setup as it is to write, which should really tell you something if people persevered with it anyway.

I'm sorry your favourite language doesnt have the recognition it so rightfully deserves, but reducing python to just "stupid language for stupid people" is, well, stupid

Python is the blub language now.

Keep in mind that when Graham coined that term Java and C++ were considered blub languages.

Speaking as a grey beard myself, I think its safe to say that the grey beards among us will always deride those who didn't have to work as hard as they did.

And Python is four years older than Java.

Python existed for years before uv with a huge ecosystem, and will continue to do so after/if it dies

uv, yes*, but really PEP 723:

https://peps.python.org/pep-0723/

* disclosure: We are a commercial client of astral.sh

It’ll probably be a game changer for scripts, yes. Writing “portable” Python scripts was a nice exercise, though (and will be, for a while).

This is cool! I ended up also inventing my own syntax to place at the top of one-off scripts to specify deps. (For single-file Python scripts, vs one with a full project dir that has pyproject.toml) I will adopt this instead.

Sounds a lot like vim/emacs modelines. This is neat for standalone scripts.

I agree uv is great but let’s not get carried away here. Poetry is good, pip was fine for many use-cases after they added native lock files.

if you are working on one tiny project on your machine that pips in four packages you probably think pip was OK.

Circa 2017 I was working on systems that were complex enough that pip couldn't build them and after I got to the bottom of it I knew it not my fault but it was the fault of pip.

I built a system which could build usable environments out of pre-built wheels and sketched out the design of a system that was roughly 'uv but written in Python' but saw two problems: (1) a Python dependent system can be destroyed by people messing with Python environments, like my experience is that my poetry gets trashed every six months or so and (2) there was just no awareness by the 'one tiny project on your machine that pips in four packages' people that there was a correctness problem at all and everybody else was blaming themselves for a problem and didn't have a clear understanding of what was wrong with pip or what a correct model for managing python dependencies is (short answer: see maven) or that a 100% correct model was even possible and that we'd have to always settle for a 97% model. The politics looked intractable so I gave up.

Now written in rust, uv evaded the bootstrap problem and it dealt with the adoption problem by targeting 'speed' as people would see the value in that even if they didn't see the value in 'correctness'. My system would have been faster than pip because it would have kept a cache, but uv is faster still.

Well said.

I have used them all and UV is the only one that actually solves the problem.

It’s insane that people would suggest that Python can go back.

> everybody else was blaming themselves for a problem and didn't have a clear understanding of what was wrong with pip or what a correct model for managing python dependencies is (short answer: see maven)

I always looked down on the Java ecosystem but if it turns out Maven had a better story all along and we all overlooked it, that's wild.

Maven has its own bone headed design where it SILENTLY resolves conflicting dependency branches through a “closest to dep tree root wins” rule.

I still believe Rust is a red herring here. Your ‘uv but written in Python’ would probably have the same success as uv does now, if you did focus on speed over correctness. And I’ve yet to hear about pipx or Poetry getting trashed, but if it is a problem, I don’t think it’s impossible to solve in Python vs Rust.

> The politics looked intractable so I gave up.

So yeah, this is your actual problem. (Don’t worry, I’m in the same camp here.)

As much as I'm a Python fan I strongly disagree here that rust is a red herring.

Having a static binary makes distribution way simplier. There are a bunch of ways you could try to achive something like in python but it would be significantly larger.

Performance-wise writing it in python would have heavy startup overhead and wouldn't be able to get close to the same level of performance.

Obviously you could achive the same thing in many other languages, but rust ends up being a really good fit for making a small static binary for this workload of network heavy, IO-bound, async/threading friendly with the occasional bit of CPU heavy work.

>>> ‘uv but written in Python’

you mean pdm?

Poetry and friends are so bad that many people continued just using pip -r requirements.txt despite knowing about this other stuff

Poetry having users isn’t the metric for success. pip having way less users is.

How is uv awesome and Poetry so bad? They do basically the same things except Astral re-invents the wheel but only part way instead of just relying on the existing tools. uv is fast. As far as I can tell, there's hardly any difference in functionality except for it also replacing PyEnv, which I never use anyway.

uv assuming your local Python is busted to hell and back helps a lot with isolation.

Poetry's CLI would often, for me, just fall over and crash. Crashing a lot is not a fundamental problem in the sense you can fix the bugs, but hey I'm not hitting uv crashes.

pipenv was even worse in terms of just hanging during package resolution. Tools that hang are not tools you want in a CI pipeline!

The end result: `uv run` I expect to work. `pipenv` or `poetry` calls I have to assume don't work, have to put retries into CI pipelines and things like that.

uv has a lot of sensible defaults that prevent clueless developers to shoot their own feet. Uv sync, for example, would uninstall packages not in pyproject.toml

i kind of disagree with this. uv run is clunky, i don't want that. i want to keep the activate the venv and do shit model. i hate uv run as a primitive.

I mean you don't need to use that then. `uv` is still writing to `.venv` by default and you can activate it with `direnv` or w/e.

the point about defaults though, the default or defacto workflow is uv run

Maybe, but that's not how I've been holding it.

I think I have trauma from virtual environments...

Performance aside, uv is more standards compliant than Poetry about the pyproject.toml.

But yes, in terms of user interface they are pretty similar. UV performance really does make the difference.

One of them is written in Rust....

I don't know if it's still true, but ~7 years ago when I last looked at it, Poetry didn't have the kind of UX I have in mind (That Astral/UV do). I remember trying to make it work, and it would choose Python 2 for some reason, despite me never having used it, and it having been obsoleted years before. I remember hitting many problems/errors I can't recall the detail of, but bad UX.

>people continued just using pip -r requirements.txt

What exactly is the issue with this?

The requirements file isn't a lockfile: running that command at different times will give you different venvs.

Right, and that's expected.

let's get carried away.

`uv run` a .py with inline script metadata has all the deps installed and your script running in a venv while poetry is still deciding to resolve...

Ahaha, I feel this comment.

I used to do backend development in superior languages, and sometimes do hobby frontend in superior languages, but my work is Python now. And it kind of has to be Python: we do machine learning, and I work with GDAL and PDAL and all these other weird libraries and everything has Python bindings! I search for "coherent point drift" and of course there's a Python library.

The superior languages I mentioned... perhaps they have like a library for JSON encoding and decoding. You need anything else? Great, now you're a library author and maintainer!

relax, soon u be rewriting the essence of all these libs into something new. python has its days numbered also perhaps for many engineering decisions that are now cheap via llms.

The LLMs write bad python as easily as any other language.

To make it good, you need to review and interate.

It is very hard to manually review AI generated code. May be we have to use another LLM to review and assume everything is good.

This hasn't been my experience. I find LLM code about as hard to review as human code, perhaps a little easier.

I think this means reviewing is the main thing with AI, and therefore the language to use should be one where reviewing is easy, for humans.

indeed, from my perspective doing heavy agentic dev for six months, the language all is implemented should be easy. its api - also. like Swift is super easy to read, but the APIs of underlying libs - not so much. Python is reasonably easy to read, but with GIL and everything is a very slow choice. Zig seems a nice apporach to readability, Rust is definitely not so readable.

we may want to invent something akin to concise math notion, but not so much, in between pseudo-code and math.

Ok, what am I missing, I've used python for many many years. What does UV give us over pip + venv + pyenv?

(I'm not doing this to be a dick, I genuinely want to know what the use case is)

Everything “just works” and is fast - and that’s basically it.

You can run a script with a one liner and it will automatically get you the same python and venv and everything as whoever distributed the python code, in milliseconds if the packages are already cached on your local computer.

Very easy to get going without even knowing what a venv or pypi or anything is.

If you are already an expert you get “faster simpler tooling” and if you are a complete beginner it’s “easy peasy lemon squeezy”.

I've used python for roughly 15 years, and 10 of those years I was paid to primarily write and maintain projects written in Python.

Things got bearable with virtualenv/virtualenv wrappers, but it was never what I would call great. Pip was always painful, and slow. I never looked forward to using them - and every time I worked on a new system - the amount of finaggling I had to do to avoid problems, and the amount of time I spent supporting other people who had problems was significant.

The day I first used uv (about is as memorable to me as the the day I first started using python (roughly 2004) - everything changed.

I've used uv pretty much every single day since then and the joy has never left. Every operation is twitch fast. There has never once been any issues. Combined with direnv - I can create projects/venvs on the fly so quickly I don't even bother using it's various affordances to run projects without a venv.

To put it succinctly - uv gives me two things.

One - zero messing around with virtualenvwrappers and friends. For whatever reason, I've never once run into an error like "virtualenvwrapper.sh: There was a problem running the initialization hooks."

Two - fast. It may be the fastest software I've ever used. Everything is instant - so you never experience any type of cognitive distraction when creating a python project and diving into anything - you think it - and it's done. I genuinely look forward to uv pip install - even when it's not already in cache - the parallel download is epically fast - always a joy.

May I ask what OS and filesystem you’re using?

All of them (well - no HPUX in 15+ years, and I've never used uv in Solaris, or AIX) - but the major two client side environments that I use 'uv' in would be WSL2+Ubuntu/ext4 (work) and macOS/APFS at home.

But - neither the speed nor constant issues with pip/virtualenvwrappers are really a function of the OS/File System.

A frequent theme in this thread (probably most clearly described in https://news.ycombinator.com/item?id=47444936) is that relying on your Python Environment to manager your Python Environment - always ends up in pain. Poetry had this issue as well.

One of the key architectural decisions of Astral was to write the Python Environment Management tooling in rust - so that it could never footgun itself.

It also benefited from very enlightened engineering decisions described here: https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

for one, it's one tool, that does the job of all three.

it just works. i'm not sure how else to describe it other than less faffing about. it just does the right thing, every time. there's a tiny learning curve (mostly unlearning bad or redundant habits), but once you know how to wield it, it's a one stop shop.

and as mentioned, it's crazy fast.

It's not horrifically slow.

> making the python ecosystem bearable

You should really qualify that statement, it implies that the Python ecosystem is bearable.

Bearable compared to what it was.

Yes please, lets start with scraping to bin whole internet using javascript and its family.

See the point ?

uv is nice, but not irreplaceable. An open source, maintenance mode fork would work just as fine. And even if all of uv disappeared today, I’d go just back to Poetry. Slower? Sure, a bit.

...and then I’ve read the rest of your comment. Please do go read the HN guidelines.

I guess it's an individual solution to that, but it's a solution that basically worsens the actual problem, as I see it, which is strict/narrow version pinning with frequent updates to latest and minimal effort to track backwards compatibility let alone try to maintain it. It just turns it into nodejs constant wrestling with package.json changes.

I would just ditch Python, like I did 8 years ago.

Personally I would stop using Python again. uv is the one thing that made it bearable.

I wish that were also true for the case of Claude/Codex/etc

UV is so much nicer than the other options.

>Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions.

Or, more relevant to this conversion: If they closed source tomorrow, the community could fork the current version.

…if tomorrow python ceased to exist, we could all go back to any number of other solutions.

I dont wanna go back to micromamba, pixi is my happy place (which builds on uv).

The “requests” package gets downloaded one billion times every month, should that be a multi billion dollar VC company as well? It’s a package manager and other neat tooling, it’s great but it’s hardly the essence of what makes Python awesome, it’s one of the many things that makes this ecosystem flourish. If OpenAI would enshittify it people would just fork or move on, that’s all I’m saying, it’s not in any way a single point of failure for the Python ecosystem.

> the essence of what makes Python awesome

This is not the point of uv or any good package manager. The point is what prevents Python to suck. For a long time package management had been horrible in Python compared what you could see in other languages.

That says more about the sad state of modern CI pipelines than anything about uv's popularity.

Not disputing that it's a great and widely used tool, BTW.

I mean, these sorts of numbers speak to the mind-bogglingly inefficient CI workflows we as an industry have built. I’d be surprised if there were 4 million people in the world who actually know what ‘uv’ is.

I do feel like it is overstated, and the number of downloads is not a good metric at all. There are npm packages with many millions of downloads, too.

You can take my padleft function from my cold dead hands, but it will live forever in example code!

It's not difficult to download something yourself 4 million times every day to look popular :)

Don't understate its importance. I've been using Python for more than 30 years. They solved a problem that a lot of smart people didn't solve (). Python developer experience improved an order of magnitude.

() Sure, they were on the shoulders of giants

Not including direct downloads via the native installers, Homebrew, Winget, or Docker, mind you.