[disgruntledphd2]

> It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day.

And this is a terrible development that we should all try to resist, as it leads to a combinatoral explosion of dependencies and problems, as soon as you introduce another language. So then we end up using docker to encapsulate things because they are hard to manage on one box.

It just seems crazy, but I don't really have much of a solution, tbh. Perhaps we could just install the build tool (in this case rustup) for supported languages and stop trying.

[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 :(