3 ms·

The solution mentioned at the start of the article is what distribution package maintainers have been doing for decades. I would take this account as a giant fl

by tgbugs 6y ago

The solution mentioned at the start of the article is what distribution package maintainers have been doing for decades. I would take this account as a giant flashing warning sign of what could happen to the flatpak/snap ecosystem, and also a flashing warning sign for languages that are developing their own package manager, especially if it is difficult for packages from the language package manager to be integrated into actual system level package managers. The curation effort required to get NPM into manageable shape is almost certainly beyond the scope of any traditional community effort.

mratsim 6y ago
Not having a package manager for your language means you're back to CMake and the "FindBoost", "FindCuda", "FindMKL", scripts that always fail for one reason or the other. It encourages reinventing the wheel instead of standing on the shoulder of giants. For smaller languages having everyone implement a JSON parsing library because there is no dependency management would be a significant hurdle that might kill off the language before it's even started. System package manager are a pain to deal with as a developer, when adding CI to my projects I'd rather deal with the language package manager, that works on Windows, MacOS, Linux rather than brew + msys2/pacman + apt-get and some C/C++ dependencies are just unavailable (looking at you recent BLAS/Lapack on Windows) It also significantly streamline the documentation. Any step you add to your git clone or foo install is an extra hurdle for package adoption. Lastly the language community needs is often at odds with the system administrator needs. You can't expect the distro package manager to deal with every single packages in the R community for example which allow you to analyze in a slightly different but niche way. This was examplified by the recent Haskell package management in Archlinux rant (link dead but was here: https://dixonary.co.uk/blog/haskell/cabal-2020 https://dixonary.co.uk/blog/haskell/cabal-2020) Now I'm not saying that system package managers are bad, I go out of my way to integrate all the Data Science libraries I use in my system: https://github.com/mratsim/arch-Data-Science https://github.com/mratsim/arch-Data-Science, but that's because here I take my sysadmin/end-user/package consumer hat.
- dane-pgp 6y ago
  > Not having a package manager for your language ... encourages reinventing the wheel instead of standing on the shoulder of giants. Isn't writing a new package manager from scratch a pretty clear example of reinventing the wheel, especially when these package managers often miss vital features that system package managers have had for 15 years? https://wiki.debian.org/SecureApt https://wiki.debian.org/SecureApt
  - hombre_fatal 6y ago
    You link a package management solution that works for a single OS and wonder why programming language libraries don't just use that? So, I have a useful library that I want to share with the world. I do what, exactly, so that other people across platforms can use it?
    - bwyeBr1j 6y ago
      Your comment is a beautiful demonstration of the problem -- a lack of understanding of the existing tool drives a desire for a new, different tool. There is absolutely nothing about apt or dpkg that are os specific other than they require a posix-like environment. The same goes for rpm and yum. And pacman. At the end of the day, these package managers all do the following: 1) describe the dependency relationships of packaged software 2) describe where to extract files 3) describe any actions that need to be taken prior to or after extracting files There's nothing stopping you from installing .debs with dpkg on an RedHat system nor .rpms with rpm on a Debian system aside from conflicts when both package managers try to put files in the same place. This same conflict occurs when language package managers come into the picture, because newsflash: someone else has been working on the same fucking problem for decades, and somewhere between just ignoring their work, and actively hampering it.
      - hombre_fatal 6y ago
        Can you give an example of a project, maybe a programming language ecosystem, that unifies some sort of publish-once, access-anywhere package system that uses those tools and works across Linux, Windows, and macOS? I don't understand what that would look like in practice. Tools like Homebrew and MacPorts don't even do what you are asserting is the obvious, trivial way to do it. And I have a feeling it isn't just because my microbrain doesn't get it. For example, I don't see how your post pitches something different than what I used to have to do with C/C++ deps and CMake back in the day, and those were not the hey days of dep management. Also, enough with the animosity. When you find yourself registering a new account because you want to sneak in some venom when talking about software dep management on an internet message board, what are you doing?

by tgbugs 6y ago

mratsim 6y ago

Not having a package manager for your language means you're back to CMake and the "FindBoost", "FindCuda", "FindMKL", scripts that always fail for one reason or the other. It encourages reinventing the wheel instead of standing on the shoulder of giants. For smaller languages having everyone implement a JSON parsing library because there is no dependency management would be a significant hurdle that might kill off the language before it's even started. System package manager are a pain to deal with as a developer, when adding CI to my projects I'd rather deal with the language package manager, that works on Windows, MacOS, Linux rather than brew + msys2/pacman + apt-get and some C/C++ dependencies are just unavailable (looking at you recent BLAS/Lapack on Windows) It also significantly streamline the documentation. Any step you add to your git clone or foo install is an extra hurdle for package adoption. Lastly the language community needs is often at odds with the system administrator needs. You can't expect the distro package manager to deal with every single packages in the R community for example which allow you to analyze in a slightly different but niche way. This was examplified by the recent Haskell package management in Archlinux rant (link dead but was here: https://dixonary.co.uk/blog/haskell/cabal-2020 https://dixonary.co.uk/blog/haskell/cabal-2020) Now I'm not saying that system package managers are bad, I go out of my way to integrate all the Data Science libraries I use in my system: https://github.com/mratsim/arch-Data-Science https://github.com/mratsim/arch-Data-Science, but that's because here I take my sysadmin/end-user/package consumer hat.

dane-pgp 6y ago
> Not having a package manager for your language ... encourages reinventing the wheel instead of standing on the shoulder of giants. Isn't writing a new package manager from scratch a pretty clear example of reinventing the wheel, especially when these package managers often miss vital features that system package managers have had for 15 years? https://wiki.debian.org/SecureApt https://wiki.debian.org/SecureApt
- hombre_fatal 6y ago
  You link a package management solution that works for a single OS and wonder why programming language libraries don't just use that? So, I have a useful library that I want to share with the world. I do what, exactly, so that other people across platforms can use it?
  - bwyeBr1j 6y ago
    Your comment is a beautiful demonstration of the problem -- a lack of understanding of the existing tool drives a desire for a new, different tool. There is absolutely nothing about apt or dpkg that are os specific other than they require a posix-like environment. The same goes for rpm and yum. And pacman. At the end of the day, these package managers all do the following: 1) describe the dependency relationships of packaged software 2) describe where to extract files 3) describe any actions that need to be taken prior to or after extracting files There's nothing stopping you from installing .debs with dpkg on an RedHat system nor .rpms with rpm on a Debian system aside from conflicts when both package managers try to put files in the same place. This same conflict occurs when language package managers come into the picture, because newsflash: someone else has been working on the same fucking problem for decades, and somewhere between just ignoring their work, and actively hampering it.
    - hombre_fatal 6y ago
      Can you give an example of a project, maybe a programming language ecosystem, that unifies some sort of publish-once, access-anywhere package system that uses those tools and works across Linux, Windows, and macOS? I don't understand what that would look like in practice. Tools like Homebrew and MacPorts don't even do what you are asserting is the obvious, trivial way to do it. And I have a feeling it isn't just because my microbrain doesn't get it. For example, I don't see how your post pitches something different than what I used to have to do with C/C++ deps and CMake back in the day, and those were not the hey days of dep management. Also, enough with the animosity. When you find yourself registering a new account because you want to sneak in some venom when talking about software dep management on an internet message board, what are you doing?