← Back to context

Comment by Biganon

1 day ago

Every single time someone asks "why?" in this thread, the answer is "well cargo does it too". Not sure what to think about that.

Not all devs have very deep knowledge of the ecosystem, some will get to use a tool only if it's part of the default set of tools they're provided. Plus, it saves on memorizing a name if you only use python once in a long while. There just isn't much of a reason not to.

I landed in python last year, the pre uv time for me. The language itself is fine, but the project organization sucked. What kind of folder structure to choose? Do I use pip, env, pipenv, poetry? How to format, and with which settings? I've read tens of blog post, all giving different choices, all equally reasonable, all having some downsides.

The great thing about uv is not that their choices are best, it's that the choices have been made, the gordian knots cut. There is a good enough standard to build upon. Future python projects will look a lot more like each other, and less time will be wasted on organizational minutiae.

As someone who has worked on package managers quite a bit in the past, and for that examined prior art across package managers, that's because Cargo is doing things very well on almost all fronts. Partially because of their RFC process and partially because they have the luxury of being a "newer" package manager that doesn't have to live with ecosystem baggage going many decades back.

There are/were definitely some weaker spots with Cargo (e.g. private registry support was meh for some time), but if one were tasked to build a package manager and were only allowed to pick a single one to take inspration from, Cargo is definitely the way to go.