2 ms·

It’s been great for C and C++ packaging. I don’t think the track record has been great for Python, Go, JavaScript, etc., all of which surfaced the same problems

• saghm 2y ago
  Yeah, this is my perception as well. My lukewarm take is that because so much of the stuff packaged was written in C/C++ for so long, the packaging systems are mostly optimized to work well with the quirks of thing written in them, but that sometimes comes at the expense of stuff written in other languages. In a lot of ways, distro package managers basically have evolved the role of pip/npm/Cargo/etc. for C/C++ packages, which leads to a mismatch when trying to also use them for other languages in pretty similar ways you might expect when trying to grapple with handling a build with an arbitrary pair of languages from the list above
• aragilar 2y ago
  Why does conda or bazel exist then? If you're willing to limit yourself to pure Python plus a sprinkling of non-python for crypto, a single language with IPC over HTTP (i.e. Go) or run in a locked-down effectively mono-lingual environment for your language (JS), then the language package manager makes sense, if you can ignore the subtle breakage that comes with each of them (e.g. Jupyterhub cannot use the PyPI distributed version of specific packages, DNS issues on MacOS). Otherwise you need a cross-language package manager, and the only thing that has appeared to scale is volunteer package maintainers (complemented in some cases by paid ones) looking after upstream-provided software.