3 ms·

>The language package manager can have so much richer information than the system one, is the thing. This is simply not true. Language package managers cannot

>The language package manager can have so much richer information than the system one, is the thing. This is simply not true. Language package managers cannot describe the entire dependency graph of a piece of software because they can't handle things that aren't written in that language. For example, there are plenty of Ruby gems that require a C compiler and C shared libraries in order to work, but those dependencies cannot be encoded in that system. System package managers can describe the entire graph, thus providing richer information. >Finally most system package managers won't let you have multiple versions of a library installed at all, which makes using more than 2 programs at the same time virtually impossible (because they usually want different versions of some dependent library or other). Yes, this is a big issue with the status quo system package managers. Fortunately, there's hope on the horizon in the form of functional package management. Functional package managers such as GNU Guix and Nix allow for an arbitrary number of variants of the same software to coexist without conflict. Additional benefits include unprivileged package management, transactional upgrades and roll backs, reproducible builds, and no central point of trust for binaries (anything can be built from source). Language package managers are good for quickly sharing code written purely in that language with other developers, but unacceptable for anything else.

sdboyer 11y ago
> Language package managers are good for quickly sharing code written purely in that language with other developers, but unacceptable for anything else. Right, so, what almost all of the FLOSS world is doing, almost all of the time. Miiiight be worth optimizing for that case. Especially if a proper PDM would compose well with larger systems...which it would!
- rekado 11y ago
  > Right, so, what almost all of the FLOSS world is doing, almost all of the time. Citation needed. I have been packaging (scientific) software for years and it's usually a happy mix of different languages and libraries.
lmm 11y ago
> This is simply not true. Language package managers cannot describe the entire dependency graph of a piece of software because they can't handle things that aren't written in that language. For example, there are plenty of Ruby gems that require a C compiler and C shared libraries in order to work, but those dependencies cannot be encoded in that system. System package managers can describe the entire graph, thus providing richer information. On the contrary, the system package manager has to have a simpler model, precisely because it has to handle multiple languages. A generic model is never going to be able to capture the ruby-specific details as well as a ruby-specific model.
- davexunit 11y ago
  Based on my experience, this also isn't true. I added support for Ruby gems in the GNU Guix package manager. The way it was done was by creating a Ruby-specific build system that Ruby-based software packages elect to use. We have a generic model that allows for many types of specific build systems to exist that deal with the domain-specific concerns. This generic models works better than a Ruby-specific model because, unlike RubyGems, Guix can capture the entire dependency graph. Take the Pg gem, for example. In order to build and use it, you need the libpq shared library. RubyGems can't encode this dependency, but Guix can. The recipe for ruby-pg is only 25 lines long: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n2669 http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/... There was a talk given at FOSDEM about foreign packages in Guix with a focus on Ruby which is worth watching or skimming the slides: https://fosdem.org/2016/schedule/event/guixmodules/ https://fosdem.org/2016/schedule/event/guixmodules/

sdboyer 11y ago

> Language package managers are good for quickly sharing code written purely in that language with other developers, but unacceptable for anything else. Right, so, what almost all of the FLOSS world is doing, almost all of the time. Miiiight be worth optimizing for that case. Especially if a proper PDM would compose well with larger systems...which it would!

rekado 11y ago
> Right, so, what almost all of the FLOSS world is doing, almost all of the time. Citation needed. I have been packaging (scientific) software for years and it's usually a happy mix of different languages and libraries.

lmm 11y ago

> This is simply not true. Language package managers cannot describe the entire dependency graph of a piece of software because they can't handle things that aren't written in that language. For example, there are plenty of Ruby gems that require a C compiler and C shared libraries in order to work, but those dependencies cannot be encoded in that system. System package managers can describe the entire graph, thus providing richer information. On the contrary, the system package manager has to have a simpler model, precisely because it has to handle multiple languages. A generic model is never going to be able to capture the ruby-specific details as well as a ruby-specific model.

davexunit 11y ago
Based on my experience, this also isn't true. I added support for Ruby gems in the GNU Guix package manager. The way it was done was by creating a Ruby-specific build system that Ruby-based software packages elect to use. We have a generic model that allows for many types of specific build systems to exist that deal with the domain-specific concerns. This generic models works better than a Ruby-specific model because, unlike RubyGems, Guix can capture the entire dependency graph. Take the Pg gem, for example. In order to build and use it, you need the libpq shared library. RubyGems can't encode this dependency, but Guix can. The recipe for ruby-pg is only 25 lines long: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n2669 http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/... There was a talk given at FOSDEM about foreign packages in Guix with a focus on Ruby which is worth watching or skimming the slides: https://fosdem.org/2016/schedule/event/guixmodules/ https://fosdem.org/2016/schedule/event/guixmodules/