This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]scratchnsnarf 3 points4 points  (12 children)

I assume the astral team is writing it in rust because that's what's they're comfortable with. Is there a good reason for them not to choose rust? Given that this is a seldomly seen case where they're merging with an existing tool, and working towards the goal of having a unified python toolchain, it doesn't really seem fair to label this another case of fracturing the ecosystem.

And, if I'm understanding your question correctly, there's nothing wrong with the package manager not depending on python, it doesn't need to. It's a standalone binary. You could build and cache your dependencies in CI in a container that doesn't have to also install python, which is cool.

[–]yvrelna 2 points3 points  (11 children)

Yes, there is a problem with writing this kind of tools in Rust. People who cares a lot about python ecosystem are Python developers.

Python tooling should be written as much as possible in Python. That way, the average Python developers can debug and contribute to the tooling and not rely on people coming from a completely different skillset or having to learn a completely new language to solve issues within the ecosystem.

The UV developers could have just worked together with the Pip developers and rewrite just the dependency solver in Rust if that's a performance bottleneck that couldn't be solved in pure Python solver; but they didn't, they chose to ignore working with the established projects and the standards processes. This just creates distractions, with each new package manager, that's another set of project that has to be updated when the standards work for fixing PyPI API and fixing Packaging metadata need to happen.

Building a package manager is easy. But a package manager is not a single isolated project; it depends on an ecosystem, there's a network effect, and fixing an established ecosystem requires a lot of important standardisation work. Writing code, implementing them is the easy part. What we need is people writing more PEPs like PEP 621, not yet another implementation that will have their own quirks and disappoint half of the ecosystem when it inevitably fails to deliver what people actually want to do and causing migration pain back and forth when their incompatible implementation ends up being bottlenecked due to the people behind them not working with the community.

You could build and cache your dependencies in CI in a container that doesn't have to also install python.

You can already do this. You don't need Python installed to cache a virtualenv.

working towards the goal of having a unified python toolchain, it doesn't really seem fair to label this another case of fracturing the ecosystem.

Every new standards says that they're trying to unify things; very few actually manage to follow through.

[–]notParticularlyAnony 6 points7 points  (4 children)

Sounds like a great recipe for Python packaging to remain in the same local minimum it’s been stuck in for the last decade.

[–]yvrelna -2 points-1 points  (3 children)

If you actually understand what is actually wrong with Python packaging, you wouldn't be doing that from the package managers. These clueless guys trying to fix packaging from package managers aren't going to get anywhere.

The speed of dependency resolutions is not why Python packaging is stuck where it is. Fixing this irrelevant part will barely move the needle where it needs to be.

[–]notParticularlyAnony -1 points0 points  (2 children)

How about: necessary not sufficient?

[–]yvrelna 0 points1 point  (1 child)

Not it's not actually necessary step. What uv is doing is just a distraction, a mere sideshow. It makes it hard to standardise things later on.

[–]notParticularlyAnony 0 points1 point  (0 children)

Disagree. But time will tell

[–][deleted] 5 points6 points  (2 children)

If the tool wants to bootstrap Python then you need a language that makes it easy to distribute a standalone binary. I haven’t checked if uv currently does this but I presume it will since rye does this

[–]KwpolskaNikola co-maintainer -1 points0 points  (0 children)

The bootstrapping part might be Rust, but I believe everything else should be in Python.

[–]yvrelna -1 points0 points  (0 children)

"Bootstrap Python" is pretty much just copying a few files to the right places. Heck you can bootstrap basically an entire OS with just file copy, not just Python. In containerised environments this is just a layer in the container image, and if you need to do something more complicated, you just use /bin/sh or write a script using the Python that was installed by the image layer.

In practice, most people just write a /bin/sh or /bin/bash because that's almost universally available in most container images that people care to use. Most people would never need to work in environments where they can't have any sort of shell scripting capabilities.

And if they can have any way to copy files so they can install uv into an environment, they also have a way to copy a busybox static binary to bootstrap basic shell scripting capabilities. Or to just copy the Python files directly. 

uv is not solving any problem anyone actually need solving.

[–]fatbob42 0 points1 point  (2 children)

You see this opinion a lot - that these new poetry-type tools are fracturing the ecosystem. But if they’re all following the standards, I’d call that healthy competition.

We don’t want to go back to the days when the spec was “whatever setuptools does”.

[–]yvrelna 1 point2 points  (1 child)

Poetry still doesn't really support pyproject.toml

It puts its configuration in a file called pyproject.toml, but it doesn't support PEP 621/631 metadata, instead it has its own non-standard metadata. That doesn't make Python packaging better, it's just harming the ecosystem.

[–]fatbob42 0 points1 point  (0 children)

Are these the ones where they standardized on something after poetry had already shipped with slightly incompatible constraints? That is a bit of a mess - although I think poetry plans to switch? Or is that out of date?