I'm sorry but you are showcasing everything that's wrong with the python packaging /environment ecosystem. You list 10 tools which all work to varying degrees of overlap between each other. Which one should one use? And you don't even need to answer that because the answer changes every year. Last year it was poetry, this year it's uv. Next year it will be some other silly attempt.

This is a bad joke. It's a mature language where the answer to: "I want to manage my programming language version and installed libraries" is that you have to try a dozen different tools, each of which will cover some but not all of your requirements to do this one simple thing.

> I've used all of these tools successfully (at different times and/or for different use cases).

And you see nothing wrong with that? Pretty much every modern language has one way (or at most just a small handful of ways) to build a library and manage your dependencies/environment. The reason is that packaging and environment management is a side show. A necessary evil we have to do so that the actual crux of our work can be done. When I set out on a project, I don't say: "I want to spend a week figuring out which is the current environment management tool supported by the python mindshare". I don't want to deal with a dozen different ways of installing the dependencies of a package. This is insane. When I pick up a language, I want to know what is the way of managing dependencies and packaging up my stuff. And I don't want this to change on a yearly basis, doubly so for a mature language.

> If you think a language that has just one tool is better, then it just means your use-cases are very narrow.

Yes, I prefer that there's a choice of tools for say time series analysis or running a web service. Competition in those areas is good. That's how innovation is driven forward.

When it comes to package and environment management, I don't want innovation, I want stability. I want one agreed way to do it so that I don't need to fuck around with things which are completely orthogonal to the work I actually want to do and that will put bread on the table. I don't want to spend brain cycles keeping up to date with yet another hare brained way of defining what is a python package.

In my view, the reason why we are in this quagmire is because the roots of python are in a fairly simple scripting language, and the packaging has not well escaped these roots. You can have loose python files, you can have directories containing python files which are automagically modules, then we had to hack in a way to package collections of modules and manage their different versions. It's all hacks upon hacks upon hacks, and it has to be backwards compatible all the way to being able to run a loose python file.

I'm not saying this is easy to solve. It's the posterchild of the "Situation: there are 15 competing standards" XKCD. The time to solve it would've been 15 years ago while Guido was still the BDFL. There are too many stakeholders now to get any sort of consensus.