You must log in or register to comment.
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.
Cool to see so many peeps on the Fedi!
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.
Those languages bring different things though:
-
Python is the language the tool is for
-
C is the implementation language of Python and is always going to be there.
-
Cython is a very similar language to Python and designed to be very familiar to Python writers.
-
Fortran is the language that BLAS and similar libraries were historically implemented in since the 70s. Nobody in the python community has to write Fortran today. Those libraries are wrapped.
-
Rust is none of the above. Bringing it into the mix adds a new barrier.
Or new possibilities… See: UV, pixi, hatch, ruff, polar, pyarrow, pydantic, data fusion, deltalake, fastuuid, granian, Robyn…
I’m not a c expert and I’m not comfortable in writing python extensions in C…
But with rust you have the compiler that, if you constraint yourself to the safe part of the rust language, is checking for you for several stupid issues. In rust, I can focus on fixing logical and other implementation errors. Coming from python I feel much more at home with rust (async, yield, iterator, generator, closure, match, walrus, etc) than with C.
-
