1. 3
  1.  

  2. 1

    OS package management is awful and unportable. Use pip or whatever and make your application deployable in a self-contained way - as a single directory, or better still, a single file, that an unprivileged user can have and run. Unless and until we get a good cross-platform OS package manager (which is probably never), that is a much better approach.

    1. 2

      I disagree, this only leads to software making assumption and not contributing to being portable in any way.

      Take elm for example. They ship binaries via npm, it’s completely unusable on any BSD. Their build system uses a custom haskell script and cabal requiring a bunch of steps on OpenBSD to build - including having wxallowed on the partition where the software is built.

      Portability isn’t just running on Linux, Windows & OS X. There are other systems and a proper build system comes a long way to help package maintainers to get your software across. Not to mention that OpenBSD package maintainers do more than just shipping a binary - packages are often patched, customized etc. to work better on the platform.

      To be honest, I think the popularity of third party package managers like pip, npm, ruby gems etc. are a result of the fragmented Linux package manager space and the tendency of major distributions (like Debian) shipping ancient package versions. I don’t think adding more package managers solves that problem.

      1. 1

        Take elm for example. They ship binaries via npm, it’s completely unusable on any BSD. Their build system uses a custom haskell script and cabal requiring a bunch of steps on OpenBSD to build - including having wxallowed on the partition where the software is built.

        I can’t read gists where I am.

        Binary packaging is not well-solved, and maybe OS package management is the best of the bad options available for doing that.

        Any decent OS should be able to run cabal these days though. I don’t know what elm are doing that requires wx but that sounds like a specific problem to be solved (or, if wx is fundamentally incompatible with haskell, then a deep problem with one or other of those), not a general issue with using package managers.

        Portability isn’t just running on Linux, Windows & OS X. There are other systems and a proper build system comes a long way to help package maintainers to get your software across.

        I run FreeBSD myself. I find software that offers a cabal package is generally much easier to get running than software that offers linux, windows and OSX packages, even though in the latter case the maintainers have probably put substantially more effort into packaging.

        Not to mention that OpenBSD package maintainers do more than just shipping a binary - packages are often patched, customized etc. to work better on the platform.

        That’s a flaw, not a feature. The software should work the same on all platforms; improvements should be applied upstream.

        To be honest, I think the popularity of third party package managers like pip, npm, ruby gems etc. are a result of the fragmented Linux package manager space and the tendency of major distributions (like Debian) shipping ancient package versions. I don’t think adding more package managers solves that problem.

        I think the main reason is that Linux package managers, and indeed all major OS package managers, are just bad. No way to install a package per-user, no way to have multiple versions of a package installed, no solution to the diamond dependencies problem…. Though being completely nonportable (for which I mostly blame Debian rules-lawyering the LSB process rather than actually adopting the common standard) doesn’t help, as you say.

        Better integration between language-specific package managers would help, but since most languages don’t have FFIs into each other it’s not that much of an issue in practice. Most languages have a C FFI, but unfortunately there are no good package managers for C libraries, only the OS package manager. What would work is having a good package manager for native libraries which could then be used for other languages that bind to those libraries, but I have no idea how to get there from here given that any package manager for native libraries will have a very tough time avoiding conflict with the OS package manager.