On Linux, you settle on a single interpreter, and makes a virtualenv for each project. Make sure to never install anything systemwide. On Windows, get used to your system being broken (oh, no problem, you already are), but it won't be because of python.
That's basically the same instructions you will have for ruby and javascript. Ruby package management is about as good as python's, while javascript is a toxic wasteland.
There are languages with better dependency management, and languages with worse ones (ok, not worse than javascript, no dependency management is still better than javascript). But python and ruby do not have much difference.
Very true but with conda and docker it's not as bad for production as it used to be. Most of the packaging issues that I run into these days are related to CUDA / C++ libraries, plain python dependencies are not really an issue.
Yes, from my perspective, at least as of 2019. Every year or two since 2010 I have to stand up a new Python project, or upgrade an existing one. I'm overdue, but packages have never not been a nightmare by comparison. The last thing I used was Pipenv, which I will praise for being a tolerable experience by the end of things, but now I hear it isn't even "the thing to use" anymore? Now it's Poetry or Conda? The problem in Python is partly an issue of the individual tools, and partly an issue of the constant churn/change in the ecosystem around them.
Ruby settled on a two-part solution, Rubygems and Bundler, over a decade ago. One is the package format, hosting server, and default distribution, the other is dependency management. In practice they are two sides of the same coin, and you don't have to give much thought to them. I hate reading reductive "It just works!" quips, but it really does apply here.
> On the Python side I think the movement has started to fix the packaging mess. It's going to take a while me thinks.
I hope you are right, but ... this is the pattern: every year or two someone decides to fix it, goes about 80% of the way to a complete solution (which is maybe 50% of the effort, of course), that becomes 'the thing to use'. But then it is abandoned because that last 20% of functionality is a lot of work, and someone else comes up with a new shiny thing, and the cycle starts again.
That's basically the same instructions you will have for ruby and javascript. Ruby package management is about as good as python's, while javascript is a toxic wasteland.
There are languages with better dependency management, and languages with worse ones (ok, not worse than javascript, no dependency management is still better than javascript). But python and ruby do not have much difference.