Chris is.Remember, people. When a tool is:
⁃ open source
⁃ built to conform to open specifications
⁃ not coupled to a service offering
It does not matter who buys the company that built the tool
mhoye@offby1 respectfully it does not matter who buys the tool _today_. If you are taking a dependency on that tool, then the owning company decides the priorities, resourcing, direction and leadership of that tool, which definitely matters.
@mhoye That is what forks are for. That's why I included the other points; conformance to standards and decoupling from a service offering means that forking the tool is about as easy as it is possible to get.
@offby1 I get what you're saying, but it's not just a question of coupling or priorities. It's about who decides growth paths and directions.
Glyph@mhoye @offby1 struggling mightily to keep my Discoursing to a minimum here but I really feel like the load-bearing part of the problematic phrasing is "does not matter". of course it matters *some*. it's also fair to say it's not totally existential. this is a tool with the broadest possible audience of python developers, so perhaps while forks remain expensive in absolute terms, the community can more easily pay the cost in this case. so while it's not "game over" it's also not nothing
@glyph @mhoye I'm responding to the absolutely batshit level of hyperbolic reaction I'm seeing on this topic. The amount it "matters" is a rounding error on the overblown panic responses I have seen on the topic.
Does it "matter" some? Yes, sure.
Is it an existential threat to Python packaging? For the love of mercy, no, that's just ridiculous.
David Zaslavsky
Tin Tvrtković
Tero Ykspetäjä@tero @glyph @mhoye I don't think so, honestly; I think the *emotion* is a genuine one on all their parts; they are hurt that their hopes about the nature of the tools and company weren't met.
I don't think those hopes were realistic, mostly, and I also think that Astral set things up so that the community would benefit even when they got their exit. Honestly, for corporate OSS, this is close to the best possible *outcome*, despite nearly the worst possible buyer.
James Bennett@offby1 My concern is more that the suite of projects in question only had such a high level of velocity, maintained-ness and polish because people were literally being paid, as their job, to do it. Once the money dries up, even the best-case outcomes still probably involve huge drop-offs in all those attributes due to the switch from "this is my job" to "this is my side/hobby project".
@ubernostrum Totally valid in terms of what future development will look like, but only barely relevant in terms of what's already there... and what's already there is a phenomenal upgrade to the python packaging experience.
@offby1 I feel like a lot of the credit given to uv actually belongs to the broader Python packaging community for working out the necessary standards to actually improve things; uv just was able to rapidly adopt and implement because it was literally someone's job (several someones) to do so. Compare to pip, where I know from personal experience that it's a struggle to get implementation of crucial new standards because it's a side project that has to fight for time even when funding is on offer.
@ubernostrum I agree with that formulation.
Again, the reaction I'm pushing back on is the one where people are (and I am not exaggerating here) saying python packaging is doomed now.
That's just not reasonable or realistic.
It's unlikely to improve as fast and consistently, but it is not doomed, and I wish that people would not react as though this was undoing what they've done that was good.
Brett Cannon@ubernostrum @offby1 If you want to see when the major workflow tools added support for something, I have it documented at https://opensource.snarky.ca/Python/Workflow/Launcher/Plans#Subcommands ; look at each page in that directory and it most have a table listing when a tool added support.
Spoiler alert: uv was not first in any case except `pylock.toml` support that I'm aware of. What uv did do is get the features in front of more people due to its popularity.
@brettcannon @offby1 To be clear I'm not saying uv was first to have things, just that I think the fact that it was literally people's day job to work on it meant they had a high average velocity that volunteer projects can't easily match.
For example, even when I had a line on potential funding for pylock.toml install support in pip, I was told it would still come down to whether a pip maintainer could find the time to supervise and review.
@ubernostrum @offby1 I was posting to support you in saying uv didn't pioneer a lot of the things they are given credit for (heck, I wrote the Python Launcher in Unix in Rust ages ago, so I used Rust for Python tooling before they did 😉).
@offby1 "conform to open specifications" also means "doesn't worry about 2 decades of backwards compatibility" like pip does.
https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html#what-uv-drops
@brettcannon Oh, most definitely. I’m not trying to argue that uv didn’t stand on the shoulders of giants here, nor that it didn’t have an easier path to success. I’m just trying to make the point that OpenAI can’t _undo_ what uv has done. That’s all.