The same problems happen in those languages — the underlying problem is someone not specifying version constraints they actually have. If you get more experience with those other languages you'll definitely encounter that with projects which aren't carefully following semantic versioning. In particular, this goes back to your previous confusion about C/C++ — if you're having a problem with those toolchains, the underlying problem is that they don't have a package manager at all and every downstream tool has to compensate for that.

The one part which is worse in Python than some of those other languages is that the default tool doesn't track all of the dependencies when you install a new package. If you're not using something like pipenv, poetry, etc. you can add "foo" to your requirements file and have it work now but break in the future if you aren't using a tool to pin specific versions (e.g. pip-tools). Some other tools like NPM or Cargo avoid that by default but that's certainly not true of all languages and it's something which is widely acknowledged as an area for improvement by the people recommending or working on the aforementioned tools.

So, my major comparator for ease of installation is a statistical programming language called R.

Both Python and R have equal numbers of C/C++ dependencies, but the only breakage I experience is with Python.

This is for a number of reasons:

1) R has CRAN (like CPAN, but for R). If your package does not build on the latest version of R, it becomes unavailable.

2) if your package has C++ dependencies, the installation will error out and say which headers its missing. This means that I can search for the header and install it.

3) Because of the removal of obsolete packages, dependencies just work and you can be assured that a package will build with a given version of R. Updates can be a problem, but they are opt-in at the package level.

The core issue with Python is the acceptance that different projects can have entirely different dependencies, which means that this breakage is relatively common.

Like, I build C/C++ on a semi-regular basis, and it can be super-painful, but Python is the only higher-level language that gives me this heartache.

Not to mention that if you install pip from the Linux repositories, you're setting yourself up for a world of pain (this actually stopped me from learning Python for a number of years).

To be fair, I mostly use conda for C/C++ dependencies as it works much better, but lots of packages are still only available through pip, which means I can't avoid the problem.

To reiterate, I am super happy with this release of pip, as it will make my life much better. It doesn't go far enough, but it is much, much better than what existed before.

Finally, Python packaging is a horrible wart on an otherwise good language, and I'm probably going to argue against using it in the future because of this.

> If your package does not build on the latest version of R, it becomes unavailable.

Wow. This would definitely make packaging much much easier, and it’s so cool R is able to do this.

I can’t imagine how angry people would get if Python ever goes there though. Each community has different tendencies, and one of Python’s I’ve observed is people really get pissed when you force them to upgrade anything.