Jacob Kaplan-Moss kicked off this fascinating conversation about [uv](https://docs.astral.sh/uv/) on Mastodon recently. It's worth reading the whole thing, which includes input from a whole range of influential Python community members …
While I haven’t used uv (been kinda out of Python for a while), and I understand the concerns some have, the Python community getting concerned about good package/project management tooling is certainly a telling “choice” about how much senior Python devs have gotten used to their ecosystem. Somewhat ditto about concern over using a more performant language for fundamental tooling (rather than pursuing the dream of writing everything in Python, which is now surely dead).
So Simon is probably right in saying (in agreement with others):
while the risk of corporate capture for a crucial aspect of the Python packaging and onboarding ecosystem is a legitimate concern, the amount of progress that has been made here in a relatively short time combined with the open license and quality of the underlying code keeps me optimistic that uv will be a net positive for Python overall
Concerns over maintainability should Astral go down may best be served by learning rust and establishing best practices around writing Python tooling in compiled languages to ensure future maintainability and composability.
I don't think it's a dream of "everything in python", but "python tools for python development". It means users of the language can contribute to the tooling.
Fair, but at some point the "dream" breaks down. Python itself is written in C and plenty of packages, some vital, rely on C or Cython (or fortran) and rust now more and more. So why not the tooling that's used all the time and doing some hard work and often in build/testing cycles?
If Guido had packaging and project management included in the standard library from ages ago, with parts written in C, no one would bat an eye lid whether users could contribute to that part of the system. Instead, they'd celebrate the "batteries included", "ease of use" and "zen"-like achievements of the language.
Somewhere in Simon's blog post he links to a blog post by Armin on this point, which is that the aim is to "win", to make a singular tool that is better than all the others and which becomes the standard that everyone uses so that the language can move on from this era of chaos. With that motive, the ability for everyday users to contribute is no longer a priority.
I don’t think y’all quite grok what uv makes so special due to your seniority. The speed is really cool, but the reason Rust is elemental is that it’s one compiled blob that can be used to bootstrap and maintain a Python development. A blob that will never break because someone upgraded Homebrew, ran pip install or any other creative way people found to fuck up their installations. Python has shown to be a terrible tech to maintain Python
Why is there often no discussion or mention of Pixi along with uv in conversations about Python tooling? Is it because uv has a lot of VC money to get attention while Pixi doesn't?
I think short answer is yes, but longer answer is also that Pixi is a drop in replacement for Conda, which is a lot less used than Pip (which uv is a replacement for).
Pixi is more than a drop in replacement for Conda. Pixi being able to replace Conda and do everything that uv does (Pixi has incorporated uv into it's tools) seems to make it a more complete toolset than uv alone.