There are highs and lows to the system, just like with any system. Pip overall was a great package manager like 15 years ago, and a big step up from easy_install for sure (n.b., I started programming around the time easy_install was going out of fashion, so my point of view is coloured by that timing).

That said, it'd be nice if pip (or some PSF-blessed successor) adopted a model more similar to that offered by poetry (and formerly, pipenv, and now, I guess, uv) at least for package locking. `pip freeze > requirements.txt` isn't fit for purpose in the age of supply chain attacks, unfortunately, and PyPI already offers a reasonably workable backend for this model, whether the community at-large agrees to this or not. There are objective benefits (biggest one being better code integrity guarantees) that outweigh the objective (largely, performance-related) drawbacks.

Do you really think Python’s consensus-driven language development is better than authoritarian?

I am honestly tired of the Python packing situation. I breathe a sigh of relief in language like Go and Rust with an “authoritative” built-in solution.

I wouldn’t mind the 30 different packaging solutions as long as there was authoritative “correct” solution. All the others would then be opt-in enhancements as needed.

I guess a good thought experiment would be if we were to design a packaging system (or decide not to) for a new PL like python, what would it look like?

> I breathe a sigh of relief in language like Go and Rust with an “authoritative” built-in solution.

I don't know about Go, but Rust's packaging isn't authoritative in the sense that I meant. There's no packaging BDFL; improvements to Rust packaging happen through a standards process that closely mirrors that of Python's PEPs.

I think the actual difference between Rust and Python is that Rust made the (IMO correct) decision early on to build a single tool for package management, whereas Python has historically had a single installer and left every other part of package management up to the user. That's a product of the fact that Python is more of a patchwork ecosystem and community than Rust is, plus the fact that it's a lot older and a lot bigger (in terms of breadth of user installation base).

Basically, hindsight is 20/20. Rust rightly benefited from Python's hard lesson about not having one tool, but they also rightly benefited from Python's good experience with consensus-driven standardization.

Was not setuptools the single tool for package management? It provided both the installer plus hooks to define packages and manage the install (plus eggs to try to manage the path). That doesn't mean the choices were the right ones (the package definition being the only thing to survive), but it seems that while cargo has the mindshare for pure-rust, when there's the need for integration with other ecosystems (as is the biggest challenge for Python), people need to switch to using meson or bazel and there appears to be some issues there.

Kind of, except that setuptools was never part of the standard library or standard distribution of Python. So it suffers/suffered from the same bootstrapping issue as the rest of Python packaging.