Hi folks - I’m assessing NixOS for the first time, and still figuring things out. I installed NixOS (with GNOME DE) and noticed that in the configuration.nix file Firefox is installed with the line programs.firefox.enable = true; instead of simply being added as a package in the environment.systemPackages list. If I search for firefox in NixOS Search it says to add it to environment.systemPackages. So, my obvious question is: why is firefox installed using the programs.firefox.enable = true; line instead? What is the difference between the two installation methods? How would I know if a program needs to be installed using one method or the other?
When you use the options, additional setup is done or just the possibility to manage configuration through other options is added.
environment.systemPackages will do barely more than adding the programs binary to PATH and add a desktop entry (if applicable). Some software does not run properly or not at all when installed like this.
The rule of thumb is, if there is an option, you should prefer it over adding the package to some package list.
1 Like
Thanks for the reply! I still find it a little odd that you have two different ways to declare a program / package in the config file. Personally, I would prefer to use just one clear method. I decided to try installing something simple like htop in both ways.
environment.systemPackages = with pkgs; [
htop
];
seems to give the same result as …
programs.htop.enable = true;
or, in nested form …
programs = {
htop = {
enable = true;
};
};
… even though htop has no declarable options. However, if I use a programs block, how do I specify whether it should be installed system-wide, or for a specific user? Can a programs block be nested inside an environment.systemPackages or users.users…. block?
They have different effects.
programs.htop.enable will allow you to use programs.htop.settings.* to adjust system wide HTOP configuration defaults.
At the same time, it will forbid to manually edit /etc/htoprc to achieve that task of system defaults.
And no, the options are usually explicitely meant to provide system wide installation and configuration.
For user specific configuration, NixOS relies on the user doing the configuration by other means, after installing the software either globally or user.users.<name>.packages or HM or hjem or nix-maid or nix-env or nix profile or whatever else you might come up with.
Of course you can also use HM, hjem, nix-maid or even GNU-stow to manage user based configuration.
1 Like
Generally you should always prefer the enable option because it will account for things that you wouldn’t have even known to account for.
Yes, both of them add to system packages, but only the second also sets htoprc.
Untrue, it has programs.htop.settings which sets the aforementioned htoprc.
2 Likes
Untrue, it has programs.htop.settings which sets the aforementioned htoprc.
Apologies - you are correct! I can see programs.htop.settings in NixOS Search . I was looking at a different package earlier that didn’t appear to have any settings/options. I must have got them mixed up.
I like the concept of NixOS, and I’ll keep tinkering and learning with the VM I’ve setup. I have two Arch Linux machines in my home lab which I might consider changing over to NixOS, but I’m nowhere near knowledgable / comfortable enough with NixOS yet to do that yet, and Arch has served me well so far.
I been on NixOS for like 5 days and i’m loving it.. so different say compared to Debian or arch.. It’s like learning a new OS all over again like you never used one Lol.. i’m reading and reading and if something comes up looking how to resolve it.
For the record, you’re not alone. This is a very common newbie footgun..
The reason there are two different ways to accomplish the “same” thing is that NixOS options use other options recursively to achieve what they’re supposed to.
environment.systemPackages is simply an option that adds a package’s binaries to $PATH (alongside some other things). Pretty much all applications with a .enable option will add themselves to that option for you +/- some small things as @NobbZ says.
However, if a package needs to do more than add themselves to $PATH (such as add a configuration file, or udev rules, or enable a kernel module, connect to dbus, run a systemd service, …) then adding the package to enviornment.systemPackages is not enough. That’s whan you add a module for your package and give it a .enable option.
Meanwhile environment.systemPackages needs to continue to exist to allow adding stuff to $PATH at all. And since not every package gets a module, end users still use that option. So, unfortunately, your config ends up with two things that look like they do the same thing.
All that said, theoretically it would be possible to make every single package a .enable thing instead of adding them to a list. That’d have a bunch of other benefits, too. This is discussed from time to time; I haven’t followed that discussion enough to know why it hasn’t happened yet.
2 Likes
Same here - I do really like NixOS so far. Also for me, ZFS support is really important, and I’ve found getting NixOS installed on ZFS to be easier than Arch - but to be fair, this might be because when I first installed Arch on ZFS it was a steep learning experience for me, and I have a good understanding of it all now. I’ve been working on replicating one of my Arch machines (the laptop I’m typing on right now) in a NixOS VM. So far I’ve got all the same apps and services installed without an issue. It’s taken a little bit of reading and countless nixos-rebuild switch operations (with occasional nix-collect-garbage -d every once in a while!), but it’s pretty much there now. The only app I haven’t found in the nix repo is Steamlink, but I managed to install that as a flatpak app without a problem (which is how I have it installed on my Arch machine anyway). The one thing I really like about NixOS, is the fact that the whole machine setup (well most of it) is captured in one or two configuration files, and this makes it easier to document your setup. Over the years tinkering with Arch, I’m sure I’ve littered my installs with packages and config files that are no longer needed … but are forgotten and won’t be garbage collected by me! Migrating my laptop over to NixOS should be easy enough - made easier by the fact that it already uses ZFS, so I should just be able to create new datasets to install NixOS into without destroying the datasets that Arch is currently installed into. But, migrating my main homelab server (also Arch on ZFS) will need me to feel way more comfortable with Nix, and a lot more planning!
@TLATER Thanks for your input! I’m sure there is some history and reason-for-being behind the various ways of installing packages in NixOS. Hopefully, eventually they’ve converge on a simpler solution rather then diverge into more options and complexity. It does seem that it would be nice if packages could all be installed via programs.xxxx.enable = true; and if these lines could be nested inside a users block then you could enable and configure programs per user, or at the system level. For example, like: users.users.jbra.programs.firefox.enable = true; or system.programs.firefox.enable = true;
I’m mostly explaining the reasons for the limitations to try and drive home that this isn’t a matter of preference - if you don’t use the options when they are available, you will eventually wake up to a broken config (like the people affected by this).
Well, that part is trivial…
but this part is completely impractical. How do you propose configuring Firefox policies (that are deliberately locked to full-system paths because they’re intended to do admin-level config) per-user? This is impossible without heavy sandboxing with all its issues, or outright patching Firefox.
User- and system-level configurations are inherently completely different, you need separate implementations for each. Declaring that the API could look similar doesn’t make it possible to implement it that way.
Things like the portable services interface (although I’m still worried about its impact on e.g. sensible sandboxing with systemd, or credential management) do make it feasible for at least the subset of applications where privileges do in fact not matter, to be fair, but those are typically not the ones that already have modules.
users.users.programs already exists on the other hand, if you want to put things in a specific user profile’s $PATH instead of the system-wide one. That option is also currently a list.
Anyway, I’m getting off-topic; I think I’ve linked you to enougn places where you might find more if you want to join the work effort to mold things into what you want 
1 Like
I think sometimes there’s a fine line between expressing criticism and asking questions. Please don’t take my questions and opinions as criticism. I’m only trying to learn the Nix ways (and the whys). This discussion has been helpful, so thank you 
.
1 Like
Let me attempt an answer from a nontechnical user. While I have a lot of experience with different OS’s from a user perspective, I have only used NixOS for a couple of months.
One practical benefit of having firefox declared is simply that it works out of the box when NixOS is installed. It would be difficult for me, as a new user, to quickly find and download a browser and install it (either way) in order to take further action needing a browser.
Now that I’m comfortable with the configuration file and adding apps non-declaratively, I’ve switched to a firefox installed with flatpak. I have two reasons, one personal and the other potentially not valid. The personal reason is that I find it useful to manage all “apps” one way, and flatpak is familiar. If the service or app is more system-oriented, I would want to declare it for the reasons others have described above. The potentially invalid reason is that it makes me comfortable that firefox will get updated promptly through flatpak, rather than requiring update as part of a system upgrade, (I think) perhaps not as frequently. I’ll be pleased to be educated on this if I’m wrong.
I must admit, I only just read through the thread you linked now. Honestly, this doesn’t fill me with confidence! The nixos devs in there are “getting dressed in public” so to speak. The thread feels quite revealing of something that has developed into this extra layer complexity on top of a typical linux distro, that is quite a departure from the norm, difficult to understand (easy on the surface, but there is a lot of complexity underneath), and not very well documented. I understand that maybe this is just where nixos is right now, and it will get better. I think NixOS is something for me to keep any eye on, but not switch to right now. Arch Linux on ZFS root with a boot environment manager (I use zectl) is a reliable and flexible setup for me.
Perhaps you are right, jbra, but right now I’m very happy. If it doesn’t work out, I will simply revert to Firefox out of the config file.