[Nix-dev] Newbie experiences with NixOS

Mateusz Kowalczyk fuuzetsu at fuuzetsu.co.uk
Tue Sep 9 20:16:40 CEST 2014 

On 09/09/2014 06:24 PM, Gergö Barany wrote:
> Hi everyone,
> 
> this is a long mail about some of the issues I ran into when I recently
> tried to install NixOS 14.04 on my home machine (which is mostly for "fun"
> and some software development, but not a server). I ended up not using NixOS
> for various reasons; I'm trying to give useful feedback, and I hope I will
> succeed in not making this read like a rant full of complaints and demands.

Feedback is always good, I will try to answer what I personally can but
I am certainly not speaking on behalf of the project.

> I'm happy to file bug reports for some of the issues mentioned below, but
> I'm not always sure what project to file them on. Should every one of the
> problems with configuration.nix/nixos-rebuild be reported against nixpkgs,
> even if might not actually concern a package definition?

Nearly all common bugs should be filed under nixpkgs and if that's not
the right repository, someone can redirect you. Other notably
repositories one might file bugs against is the ‘nix’ repository for
bugs with implementation/feature requests and ‘hydra’ repository for
bugs with the build bot. In general, ‘nixpkgs’ is a very good bet.

> My background, briefly: I've been using Linux for about 15 years now, on
> various distributions. I know much of what I need for system administration,
> but I hate actually having to tweak system stuff. I know various pure and
> impure functional and logic programming languages, but the Nix language is a
> mystery to me...
> 
> So, here goes. First some very minor comments on the website and the manual,
> then more serious issues I ran into when trying (and failing) to install
> some packages I wanted.
> 
> 
> Website and the manual:
> 
> - I found it confusing that the manual talks about adding users imperatively
>   and imperative package management very early on. Not a problem, I'm just
>   wondering why it does this in the middle of explaining how to set up a
>   nice *declarative* system.
> 
> - I found it puzzling that the package channel is to be set imperatively on
>   the command line rather than in the configuration file. This breaks the
>   nice property of the entire configuration being in one or more config
>   files.
> 
> - In the manual, it would be nice to have Appendix B avaiable as a single
>   HTML page separate from the rest of the manual. (Told you these were
>   minor comments.) That would make full-text search for some options easier.
> 
> - The installation live CD comes with Konqueror as its web browser. The
>   JavaScript of the package browser at http://nixos.org/nixos/packages.html
>   does not work in Konqueror! Did not work for me at least, and there is no
>   fallback to a simpler search page.
>   (I guess I should file this as a bug?)

Yes, it does seem like you should file this as a bug. ‘nixpkgs’ is a
good bet. Other manual improvements should be filed as issues there as
well because that's where the manual lives.

> 
> Configuration:
> 
> - I haven't gone very deep here, but if I add a user in configuration.nix
>   and do nixos-rebuild, and then modify the configuration to add extraGroups
>   (such as wheel) for that user and run nixos-rebuild --switch again, then
>   the extra group setting just seems to be ignored; the user is not added to
>   the group.
>   (Would it be OK to file this as a bug against nixpkgs? If not, what github
>   project should it be?)

You need users.mutableUsers = true; here. I think this should be clearly
stated in the manual because it's a common question.

> 
> Package installation:
> 
> - ghc. I didn't care about the exact version, just hoped that a
>   "meta-package" named "ghc" would work. Here's a complete config file I
>   tried:
> 
> { config, pkgs, ... }:
> {
>   imports = [ ./hardware-configuration.nix ];
>   boot.loader.grub.enable = true;
>   boot.loader.grub.version = 2;
>   boot.loader.grub.device = "/dev/sda";
>   services.xserver.enable = true;
>   services.xserver.displayManager.kdm.enable = true;
>   services.xserver.desktopManager.kde4.enable = true;
> 
>   environment.systemPackages = with pkgs; [
>     wget vim
>     ghc
>   ];
> }
> 
> When running "nixos-rebuild build" on this, it failed with:
> error: cannot coerce a set to a string, at /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/types.nix:98:79
>
> Needless to say, I never touched that file. If I recall correctly,
> specifying a *concrete* ghc package name did work. Using a generic name
> imperatively worked: "nix-env -i ghc" selects a derivation automagically and
> installs it.

The error message sucks but if you have some experience (which as you
say, you don't) it's simple to guess what's going on. There are two
things to answer here.

1. ‘nix-env -i ghc’ worked because ‘-i’ resolves by package name, not an
attribute name. It more-or-less makes a rough guess at what you mean by
‘ghc’. Using the attirbute names in preferable because it's not
ambiguous. Notably, systemPackages and just about everything except
‘nix-env -i’ uses these attribute names. You can query attribute names
with ‘nix-env -qaP’. This way, you'd quickly find out that you need to
specify where GHC comes from: ‘haskellPackages_ghc783.ghc’ or even just
‘haskellPackages.ghc’ would work for you. It just happens so that the
‘ghc’ attribute points to a set of things which is where the error is
coming from. Unofficially, it seems that using ‘-i’ is discouraged. I
think we should aim to change our documentation and wiki to teach about
‘-iA’ instead.

> 
> - clementine (a music player). The issue here was that by default it depends
>   on the unfree libspotify package, but there is an option to install it
>   without this library. However, it didn't work for me:
> 
> { config, pkgs, ... }:
> {
>   imports = [ ./hardware-configuration.nix ];
>   boot.loader.grub.enable = true;
>   boot.loader.grub.version = 2;
>   boot.loader.grub.device = "/dev/sda";
>   services.xserver.enable = true;
>   services.xserver.displayManager.kdm.enable = true;
>   services.xserver.desktopManager.kde4.enable = true;
> 
>   config.clementine.spotify = false;
>   environment.systemPackages = with pkgs; [
>     wget vim
>     clementine
>   ];
> }
> 
> Trying to build this fails with:
> error: Module `/etc/nixos/configuration.nix' has an unsupported attribute `boot'.
> 
> This appears to be some sort of internal error in nixos-rebuild, maybe with
> parsing the config file?

Interesting, I can replicate but I don't know where it's going wrong.
You should create an issue for this, saying that you get that error when
you add ‘config.clementine.spotify = false’ to the config.

By the way if you peek into the Clementine expression you'll see

let withSpotify = config.clementine.spotify or false;

That is, libspotify is not used by default unless you say you want it.

> 
> - swt (a Java GUI toolkit, needed by some Java programs). Trying to install
>   this (with a config file as above, only with "swt" in the package list)
>   tries to download http://eclipse.ialto.com/eclipse/downloads/drops/R-3.7.2-201202080800/swt-3.7.2-gtk-linux-x86.zip
>   and fails, since that file (and the directory it is supposed to be in)
>   doesn't exist. A file with that name is available from a more official
>   source at
>   http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.2-201202080800/swt-3.7.2-gtk-linux-x86.zip
>   I tried remounting the package store read-write and copying this file to
>   the expected place, but the installer didn't pick it up from there, it
>   tried the broken mirror again. Is there a way to inject a manually
>   downloaded file into the build process, or to specify another download
>   URL, short of modifying the Nix expression for the package?
> 

nix only cares about the sha256. You can use nix-prefetch-url to
download and put something in the store. nix will then see that it is
already available in the store and won't try to download it.

An issue/pull request opened updating the URL in the package definition
is necessary.

> These are not terrible show-stoppers, I could somehow work around each of
> them. However, for me personally, I decided that NixOS was slightly too
> immature at the moment, because I really don't enjoy solving this kind of
> system administration problems. That said, I will keep an eye on it and keep
> playing with it in a virtual machine, and if requested, I'll be happy to
> complain more :-)

It seems you managed to hit quite a combination of problems! Pretty much
all the packaging problems come from the fact that we need more people
reporting problems and people fixing problems. I hope you'll try NixOS
again in the future and have a better experience.

> Keep up the good hard work!
> 
> 
> Gergo
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

I'll open issues about Clementine and swt but I ask you to open issues
about the documentation things.

-- 
Mateusz K.

More information about the nix-dev mailing list