6 ms·

GNU Guix 0.5 released

84 points by Tsiolkovsky 13y ago

hansjorg 13y ago
For any one else wondering: >The result of package build functions is cached in the file system, in a special directory called the store (see The Store). Each package is installed in a directory of its own, in the store—by default under /nix/store. The directory name contains a hash of all the inputs used to build that package; thus, changing an input yields a different directory name. >This approach is the foundation of Guix’s salient features: support for transactional package upgrade and rollback, per-user installation, and garbage collection of packages (see Features). http://www.gnu.org/software/guix/manual/guix.html#Features http://www.gnu.org/software/guix/manual/guix.html#Features
nfoz 13y ago
Sounds similar to Nix/NixOS http://nixos.org/ http://nixos.org/
- andrewflnr 13y ago
  That's because guix is a fork of Nix.
tikhonj 13y ago
For reference: GNU Guix is a version of Nix[1] with some additional features like a Guile API. While I'm sure it makes sense in the greater context of a GNU system where everything is happy and Guile-powered, I personally do not really see a reason to use Guix over normal Nix which seems to have a greater mind share and user base. If you like this approach to package management, you might want to consider trying NixOS[2], which is a distro that uses Nix as its primary package manager. NixOS has a disproportionately high uptake in the Haskell community, so it has a very good selection of Haskell packages--if you're playing around with or actively using Haskell, that could be another bonus for NixOS. Personally, I think the idea is very cool. I will probably at least try using NixOS for my next laptop--I generally switch distros every time I get a new computer. [1]: http://nixos.org/nix/ http://nixos.org/nix/ [2]: http://nixos.org/ http://nixos.org/
- xiaomai 13y ago
  I'm a huge fan of the nix/guix projects (initially I was super excited to see a guix because I prefer scheme, but actually the Nix language is wonderful). I'm really surprised the Nix package manager doesn't have a bigger following with Mac OS X people (it's a lot more capable than homebrew, and you get binary distribution for free). One problem I ran into as a ruby guy was building gems that needed to link against a C lib. Part of the beauty of the Nix approach is that it isolates everything. The "proper" solution I guess would be to package gems as Nix packages, but it seems like there probably should be some way to let a utility know the proper build flags for a given lib.
  - zimbatm 13y ago
    Same here, Nix is exciting. The story with ruby still has some way to go before it is seamless. For each language they have an adapter that exports the language-specific package manager to nix expressions. cabal, perl, python and ruby are all supported (maybe more). In the case of ruby there is `nix` ruby gem that you can use to generate a .nix expression. Ideally you could amend it to say that nokogiri depends on libxml2 and such. Then your project could have a deps.nix file that you can install. `nix-env -f deps.nix -i` I'm also exploring different ways to work with my projects. For example creating a custom profile per project that's derived from a project-specific derivation.
    - sparkie 13y ago
      I'm not particularly a fan of the idea of static converters to nix expressions, ala cabal2nix. They require someone to run them in the first place, so you don't pick up updates to packages dynamically. I'd rather we collectively agree on a protocol for installing, updating, querying packages etc, such that each language-specific package manager can talk to others through a daemon and install foreign packages that are required for the projects. It would require a fair amount of work to update each package manager to talk it (optionally), and agree on the semantics and policies of the protocol, but I think the benefits could be huge. Using Nix/Guix as the basis for such protocol would probably be ideal due to the immutable nature of packages and ability to install side-by-side versions, and that you can specify an identity of a dependency, rather than rely on fuzzy matching of name and version.
javert 13y ago
How is this concept different from the concept of "deterministic builds"? To break that down, first: Can you get a determinisitc build from using a functional package manager? Second, is a functional package manager a better way to get deterministic builds than whatever else is used (and what that is, I have no clue)?
- xiaomai 13y ago
  Read the paper from the Nix people, it's fantastic: http://nixos.org/~eelco/pubs/nixos-jfp-final.pdf http://nixos.org/~eelco/pubs/nixos-jfp-final.pdf
- tel 13y ago
  I don't know that Nix [0] is up to building crypto-safe deterministic builds, but it certainly works to be more deterministic than most other build methodologies. Nix works very hard to ensure that during build the only resources visible to the builder are those specified in the build script. Then that build information is hashed and carried along with the result of the Nix build as its fingerprint. The fingerprint is passed on to anything which depends on the build results. The end result is that the final fingerprint of a build artifact is extremely sensitive to absolutely every choice made during the build and it's very hard for the artifact to depend on anything that hasn't been deliberately chosen in the build scripts. Together these facts help to ensure a kind of global, repeatable build determinism pretty much unheard of outside of Nix. [0] The project Guix is forking
davexunit 13y ago
Congratulations to ludovic and the other contributors! I wrote a few of the new packages in this release. The prospect of having not only an official GNU distribution but one built on such a solid package management platform is very exciting. I recommend checking out some of the package definitions in the gnu/packages directory to see how elegant the DSL is. Here's a module that I wrote: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/sdl.scm http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/... If you happen to be interested in monads in Scheme, be sure to check out guix/monads.scm. It's a good read: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.scm http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.s... Please try out the QEMU image for an early look at Guix's GNU system. If you like what you see, we could use some help packaging popular free software programs. Oh, and join the mailing list and come lurk in #guix on freenode.
- Sanddancer 13y ago
  I see some interesting parts in the dsl, but at the same time, I see some warts that would rather be shaved off. For example, requiring (sha256 (base32 "hash")) just adds cruft in my opinion. I'd say exposing a function that handles all that for you, like what nix does, would be better -- something like (hash-sha256 "hash"). Though personally, the licensing section leads a real sour taste in my mouth. Nix's licensing system is much simpler, much less politicized. Simply link to the license directly, leave the commentary elsewhere. Linking to the FSF's reasonings for every license just makes me much less inclined to experiment with it.
616c 13y ago
Is anyone using NixOS on a laptop or desktop they use frequently? This is the third time I read about it here, and I generally curious.
- ocharles 13y ago
  I have been using NixOS as my primary OS for the best part of half a year now (maybe more). I haven't looked back since :) I do warn people though - it's not as featureful as other distributions, so you have to be willing to help out. I'm approaching my 100th commit on the project, I believe.
616c 13y ago
Want your head to explore: the future of package management: an Emacs plugin when Emacs goes Guile! (Personally, I think that would be pretty cool.)
- sparkie 13y ago
  Perhaps we could have something like EDE mode (but one that people would actually use), which uses a Guile DSL to describe projects and which hooks nicely into Guix to automatically handle the dependencies of the project, and build projects in an isolated environment. With any luck we could say bye-bye to make, m4 and pkg-config too.
peterwwillis 13y ago
I just looked up the page on Nix, and, yuck. First of all, requiring the directory you install shit to to include a full cryptographic hash in its name? Do you even comprehend how completely useless the file path is now to a human? Sure you can have a directory of symlinks to make it readable again, but as we should know by now, plenty of applications bork on trees of symlinks (and you can't hardlink a directory). Plus your garbage collector depends on hardlinks (or a whole lot of tree indexing). This could have been managed in so many ways to make it a lot more user friendly. "Complete dependencies"? You mean MANDATORY dependencies? This is so fucking annoying. Now I can't install an entire OS because one package with a specific SHA is gone. So even though I could rebuild it from scratch and it could be functionally identical, with 1 bit different the SHA is hosed and now everything is useless. Not to mention even if I had it, I have to ship every single dependency to anyone any time I want to give them that package/app/etc. Fantastic. And 'scanning binaries for hashes of directories'? This has got to be the laziest, dumbest solution to a complex problem i've seen supported by GNU since...... Wait, nevermind. They've probably supported dumber things. MULTI-USERS?!? YOU MEAN A NORMAL USER CAN INSTALL A PACKAGE? GET OUT. NO PACKAGE MANAGER CAN DO THAT EXCEPT.... All of them? Atomic rollbacks/upgrades sounds nice, until you realize a program might be running other programs, which might trigger your runtime dependency checking, which might screw everything up. "Garbage collector" ? Oh. If it has hardlinks, you don't delete it. Gotcha. As far as "functional" operations go, it's been pretty well proven in production environments that you don't actually have to completely recreate a binary exactly; just approximately. Functional operations management gives techies a hard-on, but means diddly in terms of real-world problem solving. We have managed away the implicated problems years ago. WHY ARE WE STILL INSTALLING FROM SOURCE?! Did Gentoo teach you all nothing!?! Service deployment? You mean service configuration management and deployment? Sigh, here we go again. Let's combine three different things into one and pretend it's a viable solution for general operational challenges. Everything else seems handy.
- weland 13y ago
  Why are you even using a computer?
  - peterwwillis 13y ago
yaiu 13y ago
> New port to the Loongson MIPS64 processors, n32 ABI (‘mips64el-linux’) Time to fire up my yeeloong
josteink 13y ago
While I'll probably not be using this myself, tokhonj's explanation of what this is does make me a bit tickly. Nix as a whole sounds neat. Having that work with LISP/Scheme sounds even neater. But the name is horrible. Guix makes this sound like something GUI-related. A GNU implementation of X? I don't know. The name is wildly misleading. They really should consider doing something about that, because naming conventions tend to matter more than you think they do.
- sparkie 13y ago
  I dislike the name too. It's meant to be pronounced "geeks", but I imagine most people will expect to pronounce it "gwicks" or "GUI x" on first look. I'd prefer something like "Gnix", or GNU Nix, which maintains it's origin and makes it clear it's a GNU project. Or just call it "Geeks" if you want it pronounced that way.

84 points by Tsiolkovsky 13y ago

For any one else wondering: >The result of package build functions is cached in the file system, in a special directory called the store (see The Store). Each package is installed in a directory of its own, in the store—by default under /nix/store. The directory name contains a hash of all the inputs used to build that package; thus, changing an input yields a different directory name. >This approach is the foundation of Guix’s salient features: support for transactional package upgrade and rollback, per-user installation, and garbage collection of packages (see Features). http://www.gnu.org/software/guix/manual/guix.html#Features http://www.gnu.org/software/guix/manual/guix.html#Features

nfoz 13y ago

Sounds similar to Nix/NixOS http://nixos.org/ http://nixos.org/

andrewflnr 13y ago
That's because guix is a fork of Nix.

tikhonj 13y ago

For reference: GNU Guix is a version of Nix[1] with some additional features like a Guile API. While I'm sure it makes sense in the greater context of a GNU system where everything is happy and Guile-powered, I personally do not really see a reason to use Guix over normal Nix which seems to have a greater mind share and user base. If you like this approach to package management, you might want to consider trying NixOS[2], which is a distro that uses Nix as its primary package manager. NixOS has a disproportionately high uptake in the Haskell community, so it has a very good selection of Haskell packages--if you're playing around with or actively using Haskell, that could be another bonus for NixOS. Personally, I think the idea is very cool. I will probably at least try using NixOS for my next laptop--I generally switch distros every time I get a new computer. [1]: http://nixos.org/nix/ http://nixos.org/nix/ [2]: http://nixos.org/ http://nixos.org/

xiaomai 13y ago
I'm a huge fan of the nix/guix projects (initially I was super excited to see a guix because I prefer scheme, but actually the Nix language is wonderful). I'm really surprised the Nix package manager doesn't have a bigger following with Mac OS X people (it's a lot more capable than homebrew, and you get binary distribution for free). One problem I ran into as a ruby guy was building gems that needed to link against a C lib. Part of the beauty of the Nix approach is that it isolates everything. The "proper" solution I guess would be to package gems as Nix packages, but it seems like there probably should be some way to let a utility know the proper build flags for a given lib.
- zimbatm 13y ago
  Same here, Nix is exciting. The story with ruby still has some way to go before it is seamless. For each language they have an adapter that exports the language-specific package manager to nix expressions. cabal, perl, python and ruby are all supported (maybe more). In the case of ruby there is `nix` ruby gem that you can use to generate a .nix expression. Ideally you could amend it to say that nokogiri depends on libxml2 and such. Then your project could have a deps.nix file that you can install. `nix-env -f deps.nix -i` I'm also exploring different ways to work with my projects. For example creating a custom profile per project that's derived from a project-specific derivation.
  - sparkie 13y ago
    I'm not particularly a fan of the idea of static converters to nix expressions, ala cabal2nix. They require someone to run them in the first place, so you don't pick up updates to packages dynamically. I'd rather we collectively agree on a protocol for installing, updating, querying packages etc, such that each language-specific package manager can talk to others through a daemon and install foreign packages that are required for the projects. It would require a fair amount of work to update each package manager to talk it (optionally), and agree on the semantics and policies of the protocol, but I think the benefits could be huge. Using Nix/Guix as the basis for such protocol would probably be ideal due to the immutable nature of packages and ability to install side-by-side versions, and that you can specify an identity of a dependency, rather than rely on fuzzy matching of name and version.

javert 13y ago

How is this concept different from the concept of "deterministic builds"? To break that down, first: Can you get a determinisitc build from using a functional package manager? Second, is a functional package manager a better way to get deterministic builds than whatever else is used (and what that is, I have no clue)?

xiaomai 13y ago
Read the paper from the Nix people, it's fantastic: http://nixos.org/~eelco/pubs/nixos-jfp-final.pdf http://nixos.org/~eelco/pubs/nixos-jfp-final.pdf
tel 13y ago
I don't know that Nix [0] is up to building crypto-safe deterministic builds, but it certainly works to be more deterministic than most other build methodologies. Nix works very hard to ensure that during build the only resources visible to the builder are those specified in the build script. Then that build information is hashed and carried along with the result of the Nix build as its fingerprint. The fingerprint is passed on to anything which depends on the build results. The end result is that the final fingerprint of a build artifact is extremely sensitive to absolutely every choice made during the build and it's very hard for the artifact to depend on anything that hasn't been deliberately chosen in the build scripts. Together these facts help to ensure a kind of global, repeatable build determinism pretty much unheard of outside of Nix. [0] The project Guix is forking

davexunit 13y ago

Congratulations to ludovic and the other contributors! I wrote a few of the new packages in this release. The prospect of having not only an official GNU distribution but one built on such a solid package management platform is very exciting. I recommend checking out some of the package definitions in the gnu/packages directory to see how elegant the DSL is. Here's a module that I wrote: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/sdl.scm http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/... If you happen to be interested in monads in Scheme, be sure to check out guix/monads.scm. It's a good read: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.scm http://git.savannah.gnu.org/cgit/guix.git/tree/guix/monads.s... Please try out the QEMU image for an early look at Guix's GNU system. If you like what you see, we could use some help packaging popular free software programs. Oh, and join the mailing list and come lurk in #guix on freenode.

Sanddancer 13y ago
I see some interesting parts in the dsl, but at the same time, I see some warts that would rather be shaved off. For example, requiring (sha256 (base32 "hash")) just adds cruft in my opinion. I'd say exposing a function that handles all that for you, like what nix does, would be better -- something like (hash-sha256 "hash"). Though personally, the licensing section leads a real sour taste in my mouth. Nix's licensing system is much simpler, much less politicized. Simply link to the license directly, leave the commentary elsewhere. Linking to the FSF's reasonings for every license just makes me much less inclined to experiment with it.

616c 13y ago

Is anyone using NixOS on a laptop or desktop they use frequently? This is the third time I read about it here, and I generally curious.

ocharles 13y ago
I have been using NixOS as my primary OS for the best part of half a year now (maybe more). I haven't looked back since :) I do warn people though - it's not as featureful as other distributions, so you have to be willing to help out. I'm approaching my 100th commit on the project, I believe.

616c 13y ago

Want your head to explore: the future of package management: an Emacs plugin when Emacs goes Guile! (Personally, I think that would be pretty cool.)

sparkie 13y ago
Perhaps we could have something like EDE mode (but one that people would actually use), which uses a Guile DSL to describe projects and which hooks nicely into Guix to automatically handle the dependencies of the project, and build projects in an isolated environment. With any luck we could say bye-bye to make, m4 and pkg-config too.

peterwwillis 13y ago

I just looked up the page on Nix, and, yuck. First of all, requiring the directory you install shit to to include a full cryptographic hash in its name? Do you even comprehend how completely useless the file path is now to a human? Sure you can have a directory of symlinks to make it readable again, but as we should know by now, plenty of applications bork on trees of symlinks (and you can't hardlink a directory). Plus your garbage collector depends on hardlinks (or a whole lot of tree indexing). This could have been managed in so many ways to make it a lot more user friendly. "Complete dependencies"? You mean MANDATORY dependencies? This is so fucking annoying. Now I can't install an entire OS because one package with a specific SHA is gone. So even though I could rebuild it from scratch and it could be functionally identical, with 1 bit different the SHA is hosed and now everything is useless. Not to mention even if I had it, I have to ship every single dependency to anyone any time I want to give them that package/app/etc. Fantastic. And 'scanning binaries for hashes of directories'? This has got to be the laziest, dumbest solution to a complex problem i've seen supported by GNU since...... Wait, nevermind. They've probably supported dumber things. MULTI-USERS?!? YOU MEAN A NORMAL USER CAN INSTALL A PACKAGE? GET OUT. NO PACKAGE MANAGER CAN DO THAT EXCEPT.... All of them? Atomic rollbacks/upgrades sounds nice, until you realize a program might be running other programs, which might trigger your runtime dependency checking, which might screw everything up. "Garbage collector" ? Oh. If it has hardlinks, you don't delete it. Gotcha. As far as "functional" operations go, it's been pretty well proven in production environments that you don't actually have to completely recreate a binary exactly; just approximately. Functional operations management gives techies a hard-on, but means diddly in terms of real-world problem solving. We have managed away the implicated problems years ago. WHY ARE WE STILL INSTALLING FROM SOURCE?! Did Gentoo teach you all nothing!?! Service deployment? You mean service configuration management and deployment? Sigh, here we go again. Let's combine three different things into one and pretend it's a viable solution for general operational challenges. Everything else seems handy.

weland 13y ago
Why are you even using a computer?
- peterwwillis 13y ago

yaiu 13y ago

> New port to the Loongson MIPS64 processors, n32 ABI (‘mips64el-linux’) Time to fire up my yeeloong

josteink 13y ago

While I'll probably not be using this myself, tokhonj's explanation of what this is does make me a bit tickly. Nix as a whole sounds neat. Having that work with LISP/Scheme sounds even neater. But the name is horrible. Guix makes this sound like something GUI-related. A GNU implementation of X? I don't know. The name is wildly misleading. They really should consider doing something about that, because naming conventions tend to matter more than you think they do.

sparkie 13y ago
I dislike the name too. It's meant to be pronounced "geeks", but I imagine most people will expect to pronounce it "gwicks" or "GUI x" on first look. I'd prefer something like "Gnix", or GNU Nix, which maintains it's origin and makes it clear it's a GNU project. Or just call it "Geeks" if you want it pronounced that way.