Having such a basic part of a programming language be awful is inexcusable. It's not just that it takes a lot of time; even if it took no extra time, you're still wasting extra space on your computer, risking breakage on external updates, and compromising security because you can't even tell what code you're running.

"Inexcusable". You know this started in 1989 and its major competition was Perl and TCL, right?

The same issues exist in C, C++, Java and nobody seems to be complaining about those at the same volume.

People here are just very dramatic. I think I need to not read (or write) HN comments for a long time, there is some serious distorted reality about.

It is inexcusable how dramatic people are on HN.

I see you've never been to Reddit.

50% of C++ devs don't use a package manager and 27% rely on a system package manager [1]. You don't hear C++ devs complaining about these issues not because they're happy with the state of dependency management in C++ but because there's a very low rate of adoption for package management systems. That, and the state of dependency management in C++ was so bad for so long that it's viewed as a fact of life.

1. https://www.jetbrains.com/lp/devecosystem-2019/cpp/

Also with C and C++ your dependencies compile with your code into a single binary, unless you explicitly opt into using a library, and when you do it becomes a package manager's issue not yours.

That's vastly oversimplifying the problem. "DLL hell" is a term for a reason. The vast amount of effort and complexity Microsoft has put into managing this problem is proof that dependency management for C and C++ is not a solved problem.

It is not a solved problem, but it is a problem that C and C++ developers don't care about, because it is a problem of packagers.

This is why it doesn't seem so bad if you're programming in those languages.

We definitely care about it. And I don't know why you think C++ developers can just push issues onto packagers when 50% don't use any kind of package management system. Meaning compiling libraries from source.

this issue outlined above doesn't exist in java, as long as you use maven.

The issue outlined above doesn't exist in Python, as long as you use Poetry.

Maven is de facto standard dependency management in Java (most of projects use it).

Poetry is not the most used (or known) dependency management in Python.

So? Nothing is stopping you from using it in your projects, thus solving your problem for good.

If a project you want to depend on isn't using a dependency management framework, how would you then make it work in your project? You will have to do extra work to define the transitive dependencies!

What needs to happen is standardization - this has been done in java because of it's maturity. There's almost no java project that isn't using the standard maven dependency management (even projects that don't use maven, such as gradle projects, would use maven dependency management, and export themselves as an artifact usable via maven).

Javascript has an even worse problem, so python isn't alone me thinks...

There are two main ways:

First of all, Poetry locks every dependency (even transitive ones) to the version you know works. This solves the problem of the project not using dependency management properly.

Secondly, setup.py allows you to specify your dependencies there, so most libraries use and specify that, which means that that isn't that much of a problem in Python. Sure, sometimes it is, but I haven't run into that particular problem very often.

Poetry is just rather new. Give it a few.

Just use Poetry. It is good. https://poetry.eustace.io