5 ms·

I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple p

by mackal 6y ago

I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here.

Koshkin 6y ago
Great point. I think BSDs got this right with their ports. (Incidentally, NetBSD's pkgsrc supports Linux.)
Ar-Curunir 6y ago
The Linux model of package management doesn't work for newer languages. In particular it is heavily reliant on dynamic linking, which tends not to work when you have (a) an unstable ABI (b) generics (c) a culture of static linking.
- beojan 6y ago
  It works fine, you just ship the static libraries. With static linking your binaries won't have dependencies anyway. That's not to say the static linking craze is a good thing. We'd be far better off finding a way to dynamically link templates, so you get the security benefits of automatically updated dependencies that dynamic linking gives you.
gowld 6y ago
Code library managers don't belong inside OS package managers (because you want hermetic builds), unless maybe you have some Nix-live multi-manager that can provide many environments.
quacker 6y ago
> I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here. As a user of software that doesn't care how it's built, sure. But system package managers are not a solution for general development with C++, or any other language. If I want to use C or C++ to create software, how do I use libraries that aren't available in a system package manager? What if I need a version of a library that's not available in my system package manager? There are answers here but they aren't good answers (build from source, using whichever of N build tools the project happens to use, or hope there are prebuilt libs hosted somewhere) Relying on system package managers to contain dependent libraries makes cross-platform development a complete PITA (more that it already is). Now you need the specific versions of all your libraries in package managers on all platforms, which is a complete non-solution for real development.
- deleted 6y ago
  [deleted]
- otabdeveloper4 6y ago
  The problem is more or less solved - see Nix. It'll take some decades for the ideas to percolate, but language-specific package managers are definitely not the future.
  - quacker 6y ago
    > The problem is more or less solved - see Nix. Sorry, but I'm really not sure what you mean by "solved". Nix is yet another (language agnostic) package manager with certain tradeoffs. But, if there is not an available Nix package for a specific version of a library I need to use - I'm out of luck. Nix is not a build tool designed to work with arbitrary or latest development versions of libraries, for example. And, it will never solve that problem even _if_ it is technically capable of doing so - because there is no force in the world that would get all projects in all languages to use it.
    - ris 6y ago
      > Nix is not a build tool designed to work with arbitrary or latest development versions of libraries, for example Well it sort of is and it sort of isn't. The great thing about Nix is how the provided packages remain malleable. You can usually quite easily make a small override to a provided package to make it build from a specific revision of the source you desire, or add a custom patch, and Nix will just build it all for you then & there. Then you can go and rebuild bits of the rest of the distribution that depend on that using your custom version. If you so want.
    - otabdeveloper4 6y ago
      > Nix is not a build tool designed to work with arbitrary or latest development versions of libraries, for example. No, that's exactly what it's designed for and exactly how we use it. And it's not a build tool (it just calls your existing build tools under the hood), it's a system for keeping different versions of dependencies installed at the same time without errors. > because there is no force in the world that would get all projects in all languages to use it. You can write your own wrappers for the projects that are missing. It's a simple and idiomatic process.
hpb42 6y ago
Exactly. Also, i'm terrified of this idea of "library-manager download code from internet and run on this machine", without all the tests and QA of individual dependencies like we have in Linux packages. Also, i've seen so many times people adding dependencies to projects because they did not know the standard library already had what they needed. I get it, it is easier to "pip install foo" than to look for "foo" in the docs. I don't think any sane person can learn everything that is available in the standard library, but searching the docs is always insightful.
pornel 6y ago
The problem is that system-specific package managers are an obstacle to making portable programs. Even within Linux and BSD there are many flavours of package managers with slightly different naming schemes for their packages. This fragmentation makes it impossible to have dependencies that just work. You need to either make users install things manually or every author has to probe multiple package names/locations using multiple tools. Language-specific managers support all of the OSes and just work, especially for users of macOS and Windows (telling people their OS sucks may state a true fact, but doesn't solve portability problems)

by mackal 6y ago

Koshkin 6y ago

Great point. I think BSDs got this right with their ports. (Incidentally, NetBSD's pkgsrc supports Linux.)

Ar-Curunir 6y ago

The Linux model of package management doesn't work for newer languages. In particular it is heavily reliant on dynamic linking, which tends not to work when you have (a) an unstable ABI (b) generics (c) a culture of static linking.

beojan 6y ago
It works fine, you just ship the static libraries. With static linking your binaries won't have dependencies anyway. That's not to say the static linking craze is a good thing. We'd be far better off finding a way to dynamically link templates, so you get the security benefits of automatically updated dependencies that dynamic linking gives you.

gowld 6y ago

Code library managers don't belong inside OS package managers (because you want hermetic builds), unless maybe you have some Nix-live multi-manager that can provide many environments.

quacker 6y ago

> I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here. As a user of software that doesn't care how it's built, sure. But system package managers are not a solution for general development with C++, or any other language. If I want to use C or C++ to create software, how do I use libraries that aren't available in a system package manager? What if I need a version of a library that's not available in my system package manager? There are answers here but they aren't good answers (build from source, using whichever of N build tools the project happens to use, or hope there are prebuilt libs hosted somewhere) Relying on system package managers to contain dependent libraries makes cross-platform development a complete PITA (more that it already is). Now you need the specific versions of all your libraries in package managers on all platforms, which is a complete non-solution for real development.

deleted 6y ago
[deleted]
otabdeveloper4 6y ago
The problem is more or less solved - see Nix. It'll take some decades for the ideas to percolate, but language-specific package managers are definitely not the future.
- quacker 6y ago
  > The problem is more or less solved - see Nix. Sorry, but I'm really not sure what you mean by "solved". Nix is yet another (language agnostic) package manager with certain tradeoffs. But, if there is not an available Nix package for a specific version of a library I need to use - I'm out of luck. Nix is not a build tool designed to work with arbitrary or latest development versions of libraries, for example. And, it will never solve that problem even _if_ it is technically capable of doing so - because there is no force in the world that would get all projects in all languages to use it.
  - ris 6y ago
    > Nix is not a build tool designed to work with arbitrary or latest development versions of libraries, for example Well it sort of is and it sort of isn't. The great thing about Nix is how the provided packages remain malleable. You can usually quite easily make a small override to a provided package to make it build from a specific revision of the source you desire, or add a custom patch, and Nix will just build it all for you then & there. Then you can go and rebuild bits of the rest of the distribution that depend on that using your custom version. If you so want.
  - otabdeveloper4 6y ago
    > Nix is not a build tool designed to work with arbitrary or latest development versions of libraries, for example. No, that's exactly what it's designed for and exactly how we use it. And it's not a build tool (it just calls your existing build tools under the hood), it's a system for keeping different versions of dependencies installed at the same time without errors. > because there is no force in the world that would get all projects in all languages to use it. You can write your own wrappers for the projects that are missing. It's a simple and idiomatic process.

hpb42 6y ago

Exactly. Also, i'm terrified of this idea of "library-manager download code from internet and run on this machine", without all the tests and QA of individual dependencies like we have in Linux packages. Also, i've seen so many times people adding dependencies to projects because they did not know the standard library already had what they needed. I get it, it is easier to "pip install foo" than to look for "foo" in the docs. I don't think any sane person can learn everything that is available in the standard library, but searching the docs is always insightful.

pornel 6y ago

The problem is that system-specific package managers are an obstacle to making portable programs. Even within Linux and BSD there are many flavours of package managers with slightly different naming schemes for their packages. This fragmentation makes it impossible to have dependencies that just work. You need to either make users install things manually or every author has to probe multiple package names/locations using multiple tools. Language-specific managers support all of the OSes and just work, especially for users of macOS and Windows (telling people their OS sucks may state a true fact, but doesn't solve portability problems)