[hctaw]

I don't think it's terrible. Modern package management just works on a different assumption - the dependencies and their artifacts are required at build time, and for libraries they cannot assume the version required by the software exists outside the build environment or in deployment.

If all of software respected those assumptions then we wouldn't need containerization nearly to the degree we have it today.

[disgruntledphd2]

It's all fine until you start needing multiple language package managers, each with their own C/C++ dependencies, and then it gets a lot trickier.

I mean, I know how to handle it, but it's pretty depressing that I need to do it, when in the past one could rely on relatively recent versions of everything existing with a system package manager.

I always need C/C++/Java dependencies in DS, so maybe I just feel the pain points more.

[hctaw]

That's more an indictment of the sorry state of C/C++ dependencies and linkage paradigms (shared libs are an antipattern like 90% of the time, imho). If C/C++ had a standard package manager then it would be much more trivial to mix and match with other languages.

Modern package management in a nutshell is "don't do what we do in C because we learned from those mistakes."

[disgruntledphd2]

Sure, but I'm a data scientist. I need C/C++ dependencies all the time. I don't have the luxury of ignoring this problem. I really wish I did though :(