> I am always flabbergasted when people make such statement
Sit down, have a coffee, re-read your whole comments, create bullet points for your case, and try to have an *objective* look at your arguments.
- Your are frustrated with your use case, seemingly to the point where you don't care about reasonable arguments but just want to lash out at something.
- By your own description, you have a specific use case, in a specific field, in a narrower sub field.
- You are not primarily a Python developer, and use it every 3 months when you have to.
Your experience, in your field, on your project, does not make you a poster child of what everyday Python is like. Sorry for the news.
Now I get that frustration of "I just want things done and not care about that whole ecosystem", but the reality is, that's not a Python thing, it's a "that's not my preferred stack thing".
I have that same feeling whenever I need to get things done in a stack I don't know, and get stuck by something does.
I used Rust the other day and ended up in a case where I needed to implement a trait I do not own. Well that ended up not being possible. That pissed me off for a time, that *really* made the most sense for my use case. Yet... I'm not going to complain that Rust is unusable because of "trait ownership hell" on the internet.
If we let the frustration aside for a minute:
Your use case, as a fact, is very contrived.
One does not stumble into projects that need to work with different, incompatible, similarly named, versions of a same library, every day.
As I mentioned, when that need arises, library maintainers usually just create a new package, with a different name.
That is what have been done for 99.99% of package managers ever in existence, be it system package managers, or language package managers.
And the reason for it is really just common sense:
- It does not happen very often
- Whenever that happens, the solution of providing a new package is the simplest and most well established
- The pattern works, and has been used since 30 years
- It is unambiguous
Note that Rust does _not_ magically solve that problem either, as there is no one size fits all solution to this problem. The best Rust can do, is:
- In the subset use case of this problem where said dependency is solely accessed from the inside of another dependency
- And said library symbols need not be externally accessible
- And said library data structures need not be shared
- Then Rust can build the outer most dependency against a specific version of said inner dependency.