11 ms·

The guide to software development with Guix

196 points by pabs3 3y ago

brabel 3y ago
If only it worked on anything other than Linux.
- dannymi 3y ago
  It works on top of any Linux distribution. So you can for example use WSL2 on Windows with a small Linux distribution and then extract the guix binaries from the website guix.gnu.org onto there, start guix-daemon in there and use guix like that. That said, I care about bootstrappable builds, so I can't recommend using a hypervisor I can't trust (Windows Hyper-V) as a base. That's if you want the development environment. On the other hand, for using guix packs of your software, you don't even need to install guix. Just unpack the pack as-is (or use docker). Note: guix supports cross compilation, so you CAN just use --target=x86_64-w64-mingw32 and it will compile your program for Windows native just fine. The computer that is doing the building needs to be Linux- or Hurd-based, though. Sometimes people come and try to port guix to cygwin or whatever but I have no experience in how far that is. What's your use case?
- cornedor 3y ago
  Although it is not the Guix, Nix supports: x86_64-linux aarch64-linux i686-linux x86_64-darwin aarch64-darwin Perhaps some day this will also be possible for Guix, but I don't think it fits the ideology of Guix since MacOS isn't free (not as in beer).
  - Jhsto 3y ago
    Slight nitpick, Nix does support more architectures, but those are the ones with prebuilt packages. Compiling say 32 bit ARM is quite feasible, takes roughly a day for a full OS image.
  - rekado 3y ago
    Guix builds binaries for - x86_64-linux - i686-linux - aarch64-linux - powerpc64le-linux - i586-gnu
  - pxc 3y ago
    > Perhaps some day this will also be possible for Guix, but I don't think it fits the ideology of Guix since MacOS isn't free (not as in beer). I just wanna note here that the hesitation to invest in macOS support in the Guix development community is technical as well as ideological. macOS is a difficult platform to support for third-party package managers, and developer interest in macOS support is a difficulty within the Nix community, too. There's a lot of breakage on major macOS upgrades as well as some fundamental portability and hermeticity problems on the platform. That said, (as an outsider) I think it would be awesome if Guix ran on macOS, just like it's ultimately a good thing for the world and for GNU that Emacs runs pretty well on macOS.
    - pjotrk 3y ago
      I've had some luck in building it on MacOS with brew, however, the investment of learning MacOS dynamic linker is too costly at the moment, and it seems to be a blocking issue right now
      - pxc 3y ago
        There seems to be a lot of Mac hackers on HN! Maybe comments like yours will eventually inspire someone with the chops to play around and advance things. It'd certainly make for a good blog post here. :)
- mekeor 3y ago
  Actually Guix System also runs on GNU Hurd. Also one might try porting it on kFreeBSD as well.
- galdor 3y ago
  This is the only reason I haven't tried to use Guix. I love the concept, I want to use it, but it does not run on FreeBSD. And I would not invest time in a packaging system that works on my workstation but not on my servers. It is sad to see so many Linux only software, especially when there is no technical reason not to support *BSD.
  - xcdzvyn 3y ago
    I feel this. My love for BSD almost matches my love for Nix, it's unfortunate I have to choose one or the other. I'm aware Nix is closely integrated with SystemD, so availability on BSD will probably never happen (though perhaps you could use the Darwin code as a starting point?), but I'd be curious to know what in particular limits Guix from being ported.
    - galdor 3y ago
      Wait it's integrated with SystemD? What is a package management system doing with the init process? I now remember that Guix is a daemon, something that made me really wary at the time; but a SystemdD dependency is something else entirely.
      - cmm 3y ago
        NixOS can be validly viewed as a very fancy Systemd configuration toolkit. If you think about it, ultimately an instance of a modern general-purpose OS is structured as a set of services which are described for and orchestrated by, well, something. In the case of NixOS (not Nix in general!) that something is Systemd (which also happens to be used by all other major Linux distros); in the case of GuixSD that something is GNU Shepherd (which also happens to be used by GNU Hurd)
      - turboponyy 3y ago
        Nix isn't, but NixOS is, if I'm not mistaken.
        xcdzvyn 3y ago
coldblues 3y ago
I much prefer GNU Guile over Nix. Anyone else? I saw some progress being made towards making NixOS compatible with other programming languages.
- bjoli 3y ago
  Well. One is a language that has metasyntactic abilities and a decent standard library. One is not. Defining a package in guix is a lot nicer than in nix
- cmm 3y ago
  I find Nix to be very close to the perfect DSL for what it does, and I like it quite a lot. But then I never bothered to look at Guix closely -- is its DSL at least lazy? Are there any honest comparisons wrt verbosity and awkwardness of Nix and Guix for stuff both are supposed to be good at? No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?
  - medo-bear 3y ago
    Guix uses Guile, which is a general purpose scheme/lisp dialect, allowing for lazy evaluation
    - cmm 3y ago
      I know quite well what Guile and Scheme are; I was asking about the specific DSL/library/whatever combo that Guix is programmed in. The code snippets on the page which this thread is about, for example, mostly use macros that seem to mimic their Nix equivalents very closely but are marginally more verbose. I would very much like to see a compelling example where the fact that Guile has macros makes a practical difference. (Note that Nix's laziness is not an unalloyed good either, for example it is notoriously difficult to debug. But let's limit ourselves to pure expressiveness for now)
      - medo-bear 3y ago
monday_ 3y ago
How do Guix and Nix userbases and contributor resources compare? I like Guix as a standalone package manager much much more. It has first-class support for single-file environment config, and it's in lisp! But a package manager system ultimately comes down to resources poured into maintaining and supporting packages, it's a bootstrap problem. It's clear that NixOS has substantial support. What about Guix?
- Filligree 3y ago
  Nixpkgs is enormously larger. I like Guix better in principle as well, but it should be clear that its principled stance on what software can be packaged means it's a nonstarter for many people.
  - rekado 3y ago
    Guix can be extended with channels, and so there are channels like nonguix (for nonfree software) or guix-science (for software that's too messy to include in Guix proper) that go beyond what quality control keeps out of Guix proper.
  - civodul 3y ago
    Well, with more than 23K packages, it's fair to say that Guix can satisfy the needs of many people, too. A lot of programming languages are pretty well represented!
    - rekado 3y ago
      Not just 23K packages --- that's just what is in the main Guix channel. Nix has a whole bunch of packages that are created automatically, on the fly, such as most R packages. The Guix equivalent would be the humongous guix-cran channel, which provides automatically generated R packages. So I think comparing the size of package collections is less interesting than checking whether your packages are included. Personally, I would have a very hard time with Nix because I need the quality control in Guix that gets me packages that have been built completely from source without depending on opaque upstream blobs (e.g. bundled jars, minified JavaScript, etc). Because of that I wouldn't be able to use Nix productively for bioinformatics, statistics, and things like pytorch in the same way as I use Guix.
ivanb 3y ago
How would one use a modern IDE in this environment especially when you have multiple projects with different dependencies open at the same time? Would one need to install the IDE as a dependency of a project? Would all the IDEs have different settings?
- dannymi 3y ago
  That depends on what you want to containerize (which I assume you are after? If you don't containerize it works just like any other distro--it will be transparent to the IDE (because the IDE doesn't care that suddendly your gcc in PATH is in $HOME/.guix-profile/bin, or that pkg-config picks up packages in PKG_CONFIG_PATH which happen to be in /gnu/store/3248235325322332w-wrwqewewtew-libpng/lib/pkgconfig)). Personally, I containerize the weird build tools I can't fully trust (vendor toolchains etc) and have wrapper scripts (written in bash) in PATH. The IDE is none the wiser that those are containerized. It's possible to have multiple packages in a permanent custom profile, if that's what you mean (that's kinda the manifest stuff at the end of the article). Those can be started all in the same container. For example, yes, you can have a profile which contains java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain for your specific project. This does not change your specific project's package. If you are asking whether java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain would be referred to in your guix.scm, I wouldn't do that. But in your profile? yes. >Would one need to install the IDE as a dependency of a project? Why that? The IDE, like a text editor, is a developer tool and doesn't end up with the project artifacts that you are building. So it's not any kind of dependency of the project. For example when you build Java projects using Eclipse, your projects are actually built using gradle and then openjdk. So gradle is a native-input, openjdk is a build system input and Eclipse is NO dependency of your project's guix package. Your developer profile, however, can contain multiple packages (in the container). That's not what's built when you build just the package using "guix build -f guix.scm", though (those builds are isolated). Think of a profile as something like as set of packages and also environment variables that you can refer to as a whole (containerize etc) using a new fixed name. Or think of companies where you have different hats on. Depending on the hat, you would have a profile--so the developer hat doesn't actually have the tools to delete production :) Most other distributions have just one global profile, not even per user. In guix, you have a default profile ".guix-profile" per user, and you can make any number of extra ones (no sudo needed). >when you have multiple projects with different dependencies open at the same time? Hmm, I think I can see what you are getting at. I don't know whether there are IDE plugins that are guix-aware. Would be easy to do though (it would just use a custom build step as the only build step - "guix build -f guix.scm" . This automatically makes a container with your package, its build system and your package's dependencies in it and builds that (if dependency is not built yet, makes a container with that package and its dependencies in it and builds that, and so on, recursively). The IDE would then pick up the output of "guix build" which is the path to the result (somewhere in /gnu/store/...)). The path names used inside and outside the container are the same, and the dependencies are kept around for a while, so the IDE will have a good time referring to those for headers etc when debugging or doing autocomplete.
superluserdo 3y ago
What's the split like these days between users of Guix the package manager running on some other distribution vs Guix the distribution? Is one noticably more popular than the other?
- rekado 3y ago
  There are many users of Guix at research institutes who aren't running Guix System (i.e. the full system). But the difference between Guix and Guix System is pretty small; even with just Guix you get the "guix system" command, so you can build containers and VMs that run Guix System. You only can't benefit from full-system rollbacks and the integration of Guix system services.
bordercases 3y ago
Guix can certainly beat Nix on documentation, with a lot following from that.
foobarqux 3y ago
Guix generally feels much saner than Nix but guix upgrade is shockingly slow.
plaguepilled 3y ago
I love NixOS, but I am looking to move my workstation to Guix. The reason is that, it seems NixOS do not sign their packages. I've checked the messaging platforms, and while there seems to be a consensus that its not needed, I'm at present unconvinced (especially since Guix, to my knowledge, do require signing). On its own I'd actually be OK with looking past this, but the lack of documentation on mandatory access control, secure boot, and general sandbox consideration, makes me concerned on multiple fronts. Which is a shame, because like I said, NixOS is a delight to use.
- civodul 3y ago
  To be clear, I think Nix (like Guix) signs its pre-built binaries ("substitutes"). However, only Guix has signed commits in its repository (the repo contains package definitions) and a mechanism for secure updates: https://guix.gnu.org/en/blog/2020/securing-updates/ https://guix.gnu.org/en/blog/2020/securing-updates/ The problem goes well beyond though: as far as I know, Guix is the only project that has a Git repository that users can authenticate when they pull from it.

196 points by pabs3 3y ago

brabel 3y ago

If only it worked on anything other than Linux.

dannymi 3y ago
It works on top of any Linux distribution. So you can for example use WSL2 on Windows with a small Linux distribution and then extract the guix binaries from the website guix.gnu.org onto there, start guix-daemon in there and use guix like that. That said, I care about bootstrappable builds, so I can't recommend using a hypervisor I can't trust (Windows Hyper-V) as a base. That's if you want the development environment. On the other hand, for using guix packs of your software, you don't even need to install guix. Just unpack the pack as-is (or use docker). Note: guix supports cross compilation, so you CAN just use --target=x86_64-w64-mingw32 and it will compile your program for Windows native just fine. The computer that is doing the building needs to be Linux- or Hurd-based, though. Sometimes people come and try to port guix to cygwin or whatever but I have no experience in how far that is. What's your use case?
cornedor 3y ago
Although it is not the Guix, Nix supports: x86_64-linux aarch64-linux i686-linux x86_64-darwin aarch64-darwin Perhaps some day this will also be possible for Guix, but I don't think it fits the ideology of Guix since MacOS isn't free (not as in beer).
- Jhsto 3y ago
  Slight nitpick, Nix does support more architectures, but those are the ones with prebuilt packages. Compiling say 32 bit ARM is quite feasible, takes roughly a day for a full OS image.
- rekado 3y ago
  Guix builds binaries for - x86_64-linux - i686-linux - aarch64-linux - powerpc64le-linux - i586-gnu
- pxc 3y ago
  > Perhaps some day this will also be possible for Guix, but I don't think it fits the ideology of Guix since MacOS isn't free (not as in beer). I just wanna note here that the hesitation to invest in macOS support in the Guix development community is technical as well as ideological. macOS is a difficult platform to support for third-party package managers, and developer interest in macOS support is a difficulty within the Nix community, too. There's a lot of breakage on major macOS upgrades as well as some fundamental portability and hermeticity problems on the platform. That said, (as an outsider) I think it would be awesome if Guix ran on macOS, just like it's ultimately a good thing for the world and for GNU that Emacs runs pretty well on macOS.
  - pjotrk 3y ago
    I've had some luck in building it on MacOS with brew, however, the investment of learning MacOS dynamic linker is too costly at the moment, and it seems to be a blocking issue right now
    - pxc 3y ago
      There seems to be a lot of Mac hackers on HN! Maybe comments like yours will eventually inspire someone with the chops to play around and advance things. It'd certainly make for a good blog post here. :)
mekeor 3y ago
Actually Guix System also runs on GNU Hurd. Also one might try porting it on kFreeBSD as well.
galdor 3y ago
This is the only reason I haven't tried to use Guix. I love the concept, I want to use it, but it does not run on FreeBSD. And I would not invest time in a packaging system that works on my workstation but not on my servers. It is sad to see so many Linux only software, especially when there is no technical reason not to support *BSD.
- xcdzvyn 3y ago
  I feel this. My love for BSD almost matches my love for Nix, it's unfortunate I have to choose one or the other. I'm aware Nix is closely integrated with SystemD, so availability on BSD will probably never happen (though perhaps you could use the Darwin code as a starting point?), but I'd be curious to know what in particular limits Guix from being ported.
  - galdor 3y ago
    Wait it's integrated with SystemD? What is a package management system doing with the init process? I now remember that Guix is a daemon, something that made me really wary at the time; but a SystemdD dependency is something else entirely.
    - cmm 3y ago
      NixOS can be validly viewed as a very fancy Systemd configuration toolkit. If you think about it, ultimately an instance of a modern general-purpose OS is structured as a set of services which are described for and orchestrated by, well, something. In the case of NixOS (not Nix in general!) that something is Systemd (which also happens to be used by all other major Linux distros); in the case of GuixSD that something is GNU Shepherd (which also happens to be used by GNU Hurd)
    - turboponyy 3y ago
      Nix isn't, but NixOS is, if I'm not mistaken.
      - xcdzvyn 3y ago

coldblues 3y ago

I much prefer GNU Guile over Nix. Anyone else? I saw some progress being made towards making NixOS compatible with other programming languages.

bjoli 3y ago
Well. One is a language that has metasyntactic abilities and a decent standard library. One is not. Defining a package in guix is a lot nicer than in nix
cmm 3y ago
I find Nix to be very close to the perfect DSL for what it does, and I like it quite a lot. But then I never bothered to look at Guix closely -- is its DSL at least lazy? Are there any honest comparisons wrt verbosity and awkwardness of Nix and Guix for stuff both are supposed to be good at? No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?
- medo-bear 3y ago
  Guix uses Guile, which is a general purpose scheme/lisp dialect, allowing for lazy evaluation
  - cmm 3y ago
    I know quite well what Guile and Scheme are; I was asking about the specific DSL/library/whatever combo that Guix is programmed in. The code snippets on the page which this thread is about, for example, mostly use macros that seem to mimic their Nix equivalents very closely but are marginally more verbose. I would very much like to see a compelling example where the fact that Guile has macros makes a practical difference. (Note that Nix's laziness is not an unalloyed good either, for example it is notoriously difficult to debug. But let's limit ourselves to pure expressiveness for now)
    - medo-bear 3y ago

monday_ 3y ago

How do Guix and Nix userbases and contributor resources compare? I like Guix as a standalone package manager much much more. It has first-class support for single-file environment config, and it's in lisp! But a package manager system ultimately comes down to resources poured into maintaining and supporting packages, it's a bootstrap problem. It's clear that NixOS has substantial support. What about Guix?

Filligree 3y ago
Nixpkgs is enormously larger. I like Guix better in principle as well, but it should be clear that its principled stance on what software can be packaged means it's a nonstarter for many people.
- rekado 3y ago
  Guix can be extended with channels, and so there are channels like nonguix (for nonfree software) or guix-science (for software that's too messy to include in Guix proper) that go beyond what quality control keeps out of Guix proper.
- civodul 3y ago
  Well, with more than 23K packages, it's fair to say that Guix can satisfy the needs of many people, too. A lot of programming languages are pretty well represented!
  - rekado 3y ago
    Not just 23K packages --- that's just what is in the main Guix channel. Nix has a whole bunch of packages that are created automatically, on the fly, such as most R packages. The Guix equivalent would be the humongous guix-cran channel, which provides automatically generated R packages. So I think comparing the size of package collections is less interesting than checking whether your packages are included. Personally, I would have a very hard time with Nix because I need the quality control in Guix that gets me packages that have been built completely from source without depending on opaque upstream blobs (e.g. bundled jars, minified JavaScript, etc). Because of that I wouldn't be able to use Nix productively for bioinformatics, statistics, and things like pytorch in the same way as I use Guix.

ivanb 3y ago

How would one use a modern IDE in this environment especially when you have multiple projects with different dependencies open at the same time? Would one need to install the IDE as a dependency of a project? Would all the IDEs have different settings?

dannymi 3y ago
That depends on what you want to containerize (which I assume you are after? If you don't containerize it works just like any other distro--it will be transparent to the IDE (because the IDE doesn't care that suddendly your gcc in PATH is in $HOME/.guix-profile/bin, or that pkg-config picks up packages in PKG_CONFIG_PATH which happen to be in /gnu/store/3248235325322332w-wrwqewewtew-libpng/lib/pkgconfig)). Personally, I containerize the weird build tools I can't fully trust (vendor toolchains etc) and have wrapper scripts (written in bash) in PATH. The IDE is none the wiser that those are containerized. It's possible to have multiple packages in a permanent custom profile, if that's what you mean (that's kinda the manifest stuff at the end of the article). Those can be started all in the same container. For example, yes, you can have a profile which contains java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain for your specific project. This does not change your specific project's package. If you are asking whether java-eclipse-jdt-core, gcc-toolchain and gfortran-toolchain would be referred to in your guix.scm, I wouldn't do that. But in your profile? yes. >Would one need to install the IDE as a dependency of a project? Why that? The IDE, like a text editor, is a developer tool and doesn't end up with the project artifacts that you are building. So it's not any kind of dependency of the project. For example when you build Java projects using Eclipse, your projects are actually built using gradle and then openjdk. So gradle is a native-input, openjdk is a build system input and Eclipse is NO dependency of your project's guix package. Your developer profile, however, can contain multiple packages (in the container). That's not what's built when you build just the package using "guix build -f guix.scm", though (those builds are isolated). Think of a profile as something like as set of packages and also environment variables that you can refer to as a whole (containerize etc) using a new fixed name. Or think of companies where you have different hats on. Depending on the hat, you would have a profile--so the developer hat doesn't actually have the tools to delete production :) Most other distributions have just one global profile, not even per user. In guix, you have a default profile ".guix-profile" per user, and you can make any number of extra ones (no sudo needed). >when you have multiple projects with different dependencies open at the same time? Hmm, I think I can see what you are getting at. I don't know whether there are IDE plugins that are guix-aware. Would be easy to do though (it would just use a custom build step as the only build step - "guix build -f guix.scm" . This automatically makes a container with your package, its build system and your package's dependencies in it and builds that (if dependency is not built yet, makes a container with that package and its dependencies in it and builds that, and so on, recursively). The IDE would then pick up the output of "guix build" which is the path to the result (somewhere in /gnu/store/...)). The path names used inside and outside the container are the same, and the dependencies are kept around for a while, so the IDE will have a good time referring to those for headers etc when debugging or doing autocomplete.

superluserdo 3y ago

What's the split like these days between users of Guix the package manager running on some other distribution vs Guix the distribution? Is one noticably more popular than the other?

rekado 3y ago
There are many users of Guix at research institutes who aren't running Guix System (i.e. the full system). But the difference between Guix and Guix System is pretty small; even with just Guix you get the "guix system" command, so you can build containers and VMs that run Guix System. You only can't benefit from full-system rollbacks and the integration of Guix system services.

bordercases 3y ago

Guix can certainly beat Nix on documentation, with a lot following from that.

foobarqux 3y ago

Guix generally feels much saner than Nix but guix upgrade is shockingly slow.

plaguepilled 3y ago

I love NixOS, but I am looking to move my workstation to Guix. The reason is that, it seems NixOS do not sign their packages. I've checked the messaging platforms, and while there seems to be a consensus that its not needed, I'm at present unconvinced (especially since Guix, to my knowledge, do require signing). On its own I'd actually be OK with looking past this, but the lack of documentation on mandatory access control, secure boot, and general sandbox consideration, makes me concerned on multiple fronts. Which is a shame, because like I said, NixOS is a delight to use.

civodul 3y ago
To be clear, I think Nix (like Guix) signs its pre-built binaries ("substitutes"). However, only Guix has signed commits in its repository (the repo contains package definitions) and a mechanism for secure updates: https://guix.gnu.org/en/blog/2020/securing-updates/ https://guix.gnu.org/en/blog/2020/securing-updates/ The problem goes well beyond though: as far as I know, Guix is the only project that has a Git repository that users can authenticate when they pull from it.