4 ms·

Guix is not late in that there aren't many purely functional package managers out there. It's the second after Nix if I'm not mistaken, and it doesn't reinvent

Guix is not late in that there aren't many purely functional package managers out there. It's the second after Nix if I'm not mistaken, and it doesn't reinvent the purely functional wheel either; it builds on top of existing core parts of Nix. Why not use Nix? Most importantly because it's not GNU; NIH is sadly a real problem for GNU. But Nix also uses C++/Perl and a stand-alone package recipe language; Guix uses Scheme as much as possible. ISTR Guix also has some features that Nix lacks, such as unprivileged package management. Don't quote me on it though; mayhaps it's trivial to add to Nix or has already been done. Cooperating with existing infrastructure is, I imagine, very difficult for a purely functional package manager, given the whole "purely functional" aspect. :-) It's also extremely unlikely that Debian will just give up apt, and RedHad will just give up rpm. And every programming language platform seems to have its own package manager precisely because of that reason: there is no one package manager on all systems, but a proglang platform wants to offer package management on all systems, so each bake their own implemented in and special-made for the language. It's a sad state, but that's the world of software for you. http://xkcd.com/927/ http://xkcd.com/927/

seagreen 12y ago
Nix does have unprivileged package management via a CLI tool, though the absolutely fantastic describe-the-whole-system-in-one-file wonder that's configuration.nix[1] takes elevated privileges. [1] E.g: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/nixos-config/configuration.nix https://github.com/Fuuzetsu/nix-project-defaults/blob/master...
Dylan16807 12y ago
>Guix is not late in that there aren't many purely functional package managers out there. Why does almost anyone not involved in writing it care what language the package manager is written in? >Cooperating with existing infrastructure is, I imagine, very difficult for a purely functional package manager, given the whole "purely functional" aspect. :-) I don't follow. Why is that difficult? >http://xkcd.com/927/ http://xkcd.com/927/ You can have different implementations of the same standard. To make your own standard is a step beyond.
- tveita 12y ago
  Being functional has nothing to do with the language it is written in. http://www.gnu.org/software/guix/manual/html_node/Introduction.html http://www.gnu.org/software/guix/manual/html_node/Introducti... "The term functional refers to a specific package management discipline. In Guix, the package build and installation process is seen as a function, in the mathematical sense. That function takes inputs, such as build scripts, a compiler, and libraries, and returns an installed package. As a pure function, its result depends solely on its inputs—for instance, it cannot refer to software or scripts that were not explicitly passed as inputs. A build function always produces the same result when passed a given set of inputs. It cannot alter the system’s environment in any way; for instance, it cannot create, modify, or delete files outside of its build and installation directories. This is achieved by running build processes in isolated environments (or containers), where only their explicit inputs are visible." Of course, this approach has some disadvantages: http://www.gnu.org/software/guix/manual/html_node/Security-Updates.html http://www.gnu.org/software/guix/manual/html_node/Security-U... "when a package is changed, every package that depends on it must be rebuilt. This can significantly slow down the deployment of fixes in core packages such as libc or Bash, since basically the whole distribution would need to be rebuilt."
  - Dylan16807 12y ago
    Oh, sorry, I got confused by the mention of Scheme. Though that means the XKCD comic doesn't apply. This is a standard with a very specific goal, and it very much does not want to incorporate a lot of the earlier standards.
    - taylanub 12y ago
      The comic was applied to the situation somewhat liberally. :-) I guess you could say it's about de-facto standards here, rather than standards. Deb, RPM, pacman, Nix, etc., as well as all the language-specific PMs all solve the broad problem of package management, so one of them could become the de-facto standard and embrace the others, but it ain't gonna happen.
  - taylanub 12y ago
taylanub 12y ago
Late clarification because I wasn't careful and forgot that "NIH" has very negative connotations: When I say "NIH is sadly a real problem for GNU," what I mean is that NIH can be an actual valid reason for GNU to fork or reinvent something, not that they're guilty for doing so. As in, it's unfortunate that they'd have to do it, but sometimes they have to. (Often it's not "reinvent" at all though, instead merely maintain an upstream compatible fork such as IceCat or Linux-libre.) The reason is that if a non-GNU project is heavily relied on by GNU, the project might one day decide that they don't exactly agree with GNU anymore, so it's best to have a fork under GNU which can be fully trusted. Sometimes I find this non-trusting stance sad, but it seems to be necessary; just see Mozilla adding DRM to Firefox. :-(

seagreen 12y ago

Nix does have unprivileged package management via a CLI tool, though the absolutely fantastic describe-the-whole-system-in-one-file wonder that's configuration.nix[1] takes elevated privileges. [1] E.g: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/nixos-config/configuration.nix https://github.com/Fuuzetsu/nix-project-defaults/blob/master...

Dylan16807 12y ago

>Guix is not late in that there aren't many purely functional package managers out there. Why does almost anyone not involved in writing it care what language the package manager is written in? >Cooperating with existing infrastructure is, I imagine, very difficult for a purely functional package manager, given the whole "purely functional" aspect. :-) I don't follow. Why is that difficult? >http://xkcd.com/927/ http://xkcd.com/927/ You can have different implementations of the same standard. To make your own standard is a step beyond.

tveita 12y ago
Being functional has nothing to do with the language it is written in. http://www.gnu.org/software/guix/manual/html_node/Introduction.html http://www.gnu.org/software/guix/manual/html_node/Introducti... "The term functional refers to a specific package management discipline. In Guix, the package build and installation process is seen as a function, in the mathematical sense. That function takes inputs, such as build scripts, a compiler, and libraries, and returns an installed package. As a pure function, its result depends solely on its inputs—for instance, it cannot refer to software or scripts that were not explicitly passed as inputs. A build function always produces the same result when passed a given set of inputs. It cannot alter the system’s environment in any way; for instance, it cannot create, modify, or delete files outside of its build and installation directories. This is achieved by running build processes in isolated environments (or containers), where only their explicit inputs are visible." Of course, this approach has some disadvantages: http://www.gnu.org/software/guix/manual/html_node/Security-Updates.html http://www.gnu.org/software/guix/manual/html_node/Security-U... "when a package is changed, every package that depends on it must be rebuilt. This can significantly slow down the deployment of fixes in core packages such as libc or Bash, since basically the whole distribution would need to be rebuilt."
- Dylan16807 12y ago
  Oh, sorry, I got confused by the mention of Scheme. Though that means the XKCD comic doesn't apply. This is a standard with a very specific goal, and it very much does not want to incorporate a lot of the earlier standards.
  - taylanub 12y ago
    The comic was applied to the situation somewhat liberally. :-) I guess you could say it's about de-facto standards here, rather than standards. Deb, RPM, pacman, Nix, etc., as well as all the language-specific PMs all solve the broad problem of package management, so one of them could become the de-facto standard and embrace the others, but it ain't gonna happen.
- taylanub 12y ago

taylanub 12y ago

Late clarification because I wasn't careful and forgot that "NIH" has very negative connotations: When I say "NIH is sadly a real problem for GNU," what I mean is that NIH can be an actual valid reason for GNU to fork or reinvent something, not that they're guilty for doing so. As in, it's unfortunate that they'd have to do it, but sometimes they have to. (Often it's not "reinvent" at all though, instead merely maintain an upstream compatible fork such as IceCat or Linux-libre.) The reason is that if a non-GNU project is heavily relied on by GNU, the project might one day decide that they don't exactly agree with GNU anymore, so it's best to have a fork under GNU which can be fully trusted. Sometimes I find this non-trusting stance sad, but it seems to be necessary; just see Mozilla adding DRM to Firefox. :-(