Guix: Unifying provisioning, deployment, and management in the age of containers
archive.fosdem.org
archive.fosdem.org
What might throw people off is that it is functional (which applies to Scheme/Guile as well).
I think the biggest problem of Nix is that the area it covers is so vast and because of that it is suffering from not having enough people working on it, which also affects the quality of the documentation. I don't know where Guix is in this area.
Regarding the language being dynamic, I recently found that there's work on making a typed language: https://github.com/tweag/nickel
Perhaps it can solve this problem.
When I got into Nix and Guix I tried both and I leaned towards Guix because "it's scheme" but ended up sticking to Nix because of maturity, Darwing support and it being way more performant.
In the end I realized that I actually prefer Nix as a language. I like that it's a very simple and limited language, with, for example, no way of performing side-effects. It is tailored towards it's purpose and, while not perfect, it does the job well.
As other point out, Nixpkgs and the Nix toolchain in general just uses very weird names for everything, plus the docs. That's the difficult bit. It's slightly improving over time.
When you face problems, I'm sure it's more likely that you won't know how to do it with NixOS/Nixpkgs, rather than you'll know exactly what needs to be done but don't know how to express it in Nix-lang.
Perhaps this will change with more doc reading, but it is anything but intuitive (coming from a C, Perl, Java, JS, PHP, Python, Go, et c background).
> What might throw people off is that it is functional
None of the languages you list are functional, so that could still explain it.
I'm still sort of confused why it needed its own DSL and couldn't have just reused an existing language.
Also, I don't understand how people can say the semantics is fine but the syntax is challenging. Syntax is entirely superficial. And if you are having trouble reading the syntax, how can you be sure the semantics isn't challenging?
There are a lot of funny fixed points used in Nixpkgs and that is challenging to think about.
- functional with no side effects (for the same imput you always supposed to get the exact same output); derivation is function of its inputs (e.g. source code, dependencies, compiler flags, architecture and so on) if none of them changes you're expecting to get the same file. Introducing side effects would remove this guarantee, and introduce bugs. - lazily evaluated - you can specify multiple things but Nix will process only the ones that are referenced, this makes weird experience that the code isn't executed from top to bottom (as most people would expect)
Those two things essentially makes the derivation declarative. You specify what derivation you want and what it needs (like dependencies) you can also use the language to transform the inputs to the way you like and still preserving the guarantee that if one dependency changes the project needs to be rebuilt.
Nix DSL, Haskell, OCaml, declarative UI libraries, Rx and other declarative paradigms are fairly different and do require a bit of new learning. They go way beyond functional programing basics like map and filter.
The Nix expression language is in essence just JSON with functions comprising of the following building blocks:
* Primitive values (strings, numbers, paths, booleans, null)
* Lists and sets
* Variables
* Functions
* Conditionals
* Assertions
* Arithmetic operators
And that's basically it. All of this is succinctly explained in the official documentation[1].
[1]: https://nixos.org/manual/nix/stable/#ch-expression-language
As a nix-lang fan, I've been using dhall as a nix-like build system configuration language when I need to work outside of the nix ecosystem. I love its use of static typing, but it's not without its rough edges. Defining recursive types is not simple and writing configs which need to mix rigidly-typed domain knowledge with arbitrary loose json data can be very tricky.
It looks nickel's authors have these use cases in mind. I'm excited to keep an eye on this project.
Edit: actually looking at contributions Yann Hamdaoui seems like the main contributor, but I saw Eelco contributing to it.
I think what people actually mean is that Nixpkgs is confusing, because that has a ton of weird utility/helper functions that you just need to know, esp. when it comes to what argument they take (which being dynamic doesn't help with at all) and Nixpkgs functions have historically had bad documentation.
Strongly disagree. The Nix custom language is just basically JSON + lambda functions. Way easier to deal with and understand then the mess of the Scheme ecosystem(s).
One interesting architectural difference between Guix and Nix is there is no separation in Guix like what you see with Nix and nixpkgs. Guix and the packages are all just one massive repo of scheme. For Guix this tighter integration can be a development advantage. I cannot imagine how this can benefit targeting multiple platforms, which Nix is able to do with Linux, Mac, FreeBSD (as of 2020), yet somehow, Guix is able to pull off cross-platform support for GNU Hurd.
What separation is there in Nix? The whole system is just a big derivation the same way as a small package is.
There are no other official channels, but a bunch of people have their own channels with additional packages. The most popular is probably nonguix (https://gitlab.com/nonguix/nonguix) which provides some popular nonfree packages.
Creating a recipe is generally easy (it's just a bunch of metadata) and even easier if it's supported by one of the importers (python, perl, emacs, ...). You can use guix on any other Linux system if you're not ready to install the complete system. The only difference is that your system is not managed by guix, and you can't run "guix system reconfigure", but the experience is otherwise the same. Make sure to follow the additional steps from the manual.
- slack
- kubectl
- terraform
- azure-cli
- cscope
There have been a several other missing tools for personal use that I just ended up packaging and sharing upstream. For the ones listed above, though, I just haven't gotten around to it, so I let Nix fill in the gap, hehe. FWIW, Guix already has Nix packaged and available as a service, so having parallel stores is really straightforward.
Debian also used to do this until Mozilla changed their tune on a few things. Debian's version and Icecat both used to be named IceWeasel, though, making fun of Mozilla.
But as of now, it lacks some basic stuff like KDE suit. The nonguix channel AFAIK doesn't have binary builds so you'll be building quite a few packages yourself. Using nonguix also means you can't expect support in official support channels. Just something to know before you start.
If this is true, it is a deal breaker for me. I try to buy open source hardware when I can, but even systems like the Pinebook Pro will have their functionality significantly limited by the absence of the linux-firmware package. It is a simple fact that most common WiFi chipset require non-free firmware.
nonguix channel AFAIK doesn't have binary builds so you'll be building quite a few packages yourself
Edit: I'm not sure if I'm reading this right, but the job says 0 builds (eg. https://mirror.brielmaier.net/eval/97958?status=succeeded&pa...). I'm not familiar with how guix works, but where can I see list of actual built derivations for a particular job?
Guix, on the other hand, is better suited for the more adventurous folks. It's built on Scheme, which many find appealing.
Both Nix and Guix can be installed on other Linux distros. Both are now available in the official Debian repository. Additionally, Nix supports macOS quite well. It even supports FreeBSD and Cygwin too, although it's probably not as mature.
As a user who occasionally makes my own packages for software deployment, I can learn very quickly how to write a package description by grepping through the guix main repo and looking at how other packages are written. That's probably similar for Nix, but it's something that I found refreshingly clean and flat in guix and I'm frankly hooked.
Considering I have all my daily use software already installed in Arch, if I attempted to re-install them with Guix in parallel, would that lead to namespace collisions? (i.e. would I have to uninstall currently installed software before I re-install them with Guix?)
Here you go: https://guix.gnu.org/manual/en/html_node/Binary-Installation...
> if I attempted to re-install software with Guix in parallel, would that lead to namespace collisions?
It shouldn't. That's one thing Guix (and Nix) excel at: packages only refer to specific versions of their inputs, so you can even install multiple versions of the same package at once if you want.
In terms of Guix shadowing packages installed by Arch, you can put $HOME/.guix-profile either at the front or the end of your $PATH depending on whether you want to prioritize Guix or Arch packages. When I was getting my feet wet with Guix, I ran Guix on top of Gentoo (doing basically what you suggested, gradually shadowing Gentoo packages with Guix ones) for a few months without any significant problems.
Could I ask you to compare guix and portage? I'm not an expert in either, but it looks like guix provides very similar source builds with easier binary caching/substitution.
Namespacing in this case is just adding the guix bin directory to your PATH; put it in front of your existing path to default to guix programs, or at the end to default to Arch. You can also just use an ad-hoc environment (https://guix.gnu.org/manual/en/html_node/Invoking-guix-envir...) to call guix packages at will without really installing them.
Guix is more elegant in ways such as guile versus nix the dsl, although the haskell underpinning of nix is very useful.
If you're a linux user willing to put in the time and play around then both are perfectly usable as daily drivers but they're both learning experiences as well.
Hard to say which will win out, probably both, with excellent interoperability.
They really are the future of os managment, they simplify abstractions of state and naming
The idea of two functional, declarative package/system managers being interoperable is very exciting for me, if it meant I can use full breadth of Nixpkgs with system config declared in Guile. But is that something I can look forward to or is it too much?
I thought Nix was written in C++?
For many Haskellers, I believe the interest stems from how Haskell's "cabal-install" (its closest equivalent to pip, cargo etc) used to be pretty broken. There wasn't universal interest in fixing this, with some insisting that installing dependencies is the job of your distro's package manager, not your language's ecosystem.
Gentoo did an okay job at having coverage of Haskell dependencies, but Nix was the clear leader ever since they could auto-import the hackage database. It's for this sole reason that I moved from Gentoo to Nix.
This pipeline I came through doesn't really exist now, because the Haskell community has endorsed Stackage, and cabal has fixed its core problems by copying the nix solution.
It'll probably work as a daily driver if you mainly live in a web browser and don't do GPGPU/games/new languages/etc. If you don't mind building from source you can even do most of those.
For what it's worth the project seems very well structured and the contributors very competent and motivated. I am tracking the project.
For what it's worth, I use Guix and I've been able to do everything but CUDA just fine. (CUDA will never be supported in Guix as it requires proprietary drivers to function.) There are opencl packages, for example. It works well enough to run an Ethereum miner, Blender, and even games in WINE. I've been meaning to package AMD ROCm for better GPU compute support.
What the best guide or documentation if that would be a my goal?
Not sure if there's a full howto for your purpose, but you'd want to look into manifests: https://guix.gnu.org/en/blog/2019/guix-profiles-in-practice/
There is a guix command for generating a manifest from the current profile as well, but it's not mentioned in the above link: guix package --export-manifest