Question Regarding configuration.nix

Learning as I go and tweak things. Totally broke the system once, to the point I couldn’t log in as root or user, at which point I copied my configuration.nix file, edited out my mistakes, and reinstalled (rollback didn’t work). Learning from mistakes.

I’ve installed software via nix-env, some free, some unfree. My question is, should I be listing all of my software choices in the configuration.nix file? Just some of them? The basics? Still trying to get a handle of that part. I’m assuming the unfree stuff shouldn’t be listed as I don’t think it would install during rebuild, or am I wrong about that?

It’s a single user machine.

Thanks in advance for any and all input and advice.

1 Like

Hi,
relatively new NixOS user here, so… My strategy is simple: anything
MUST go in configuration not done by hand, simply because doing so
let you reinstall/replicate your complete setup anywhere simply
copying your config. IMO the ability to install stuff via CLI have to
considered harmful…

To ease config reading I split in few files in /etc/nixos, more in
details:

  imports =
    [
      ./hwconfig.nix
      ./pkgs.nix
      ./firewall.nix
      ./xserver.nix
      ./services.nix
      ./derivations.nix
      ./unstablepkg.nix
      ./cronjobs.nix
    ];

configuration.nix only contain boot setup, main user setup (since I’m
on a personal desktop so I haven’t to deal with many users), network
setup (just because, as above a personal desktop have a simple net
setup) and very few other stuff, pkgs are

  environment.systemPackages = with pkgs; [
    ...
    zsh zsh-completions pavucontrol ...
  ];

plus settings like

  nixpkgs = {
    config = {
      packageOverrides ...

    allowUnfree = true;
    virtualbox.enableExtensionPack = true;

    ...

   };
  };

To have unstable pkg on NixOS stable

{ config, pkgs, ... }:

let
  unstableTarball =
    fetchTarball
      https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz;
in
{
  nixpkgs.config = {
    packageOverrides = pkgs: {
      unstable = import unstableTarball {
        config = config.nixpkgs.config;
      };
    };
  };

  environment.systemPackages = with pkgs; [
    unstable.masterpdfeditor unstable.anydesk
    # all pkg you want ... ... ... ...
  ];
}

You may also like homeManager when you start feeling at home with NixOS
so a certain part of your config may go there. If you are an Emacs user
perhaps you’ll like to put config in org-mode and sudo tangle to the
right place so with a simple backup of your home/your datas you can also
replicate the system that enable you to use those datas :slight_smile:

– Ingmar

3 Likes

My workflow the programs going into the configuration is this:

  1. Install with nix-env and see if it is a useful addition to my system
  2. From time to time I go though nix-env -q and uninstall or move to configuration if it has proven worthy
4 Likes

relatively new NixOS user here, so… My strategy is simple: anything
MUST go in configuration not done by hand, simply because doing so
let you reinstall/replicate your complete setup anywhere simply
copying your config. IMO the ability to install stuff via CLI have to
considered harmful…

In general, of course, one can do some things via configuration and some
things via separate expressions for use with nix-shell or just
nix-build.

The reason for that might be that different subsets of things take
different time to rebuild and have different freshness requirements, so
rebuilding Chromium (used only for testing) doesn’t hold up the update
of Firefox (which I actually care about).

nix-env … well, it has a lot of useful applications, but I am not sure
plain nix-env -i package (and even nix-env -iA package) are
something to use if you already want to use NixOS.

1 Like

I agree that installing packages through nix-env is an antipattern. I go so far as to having an activation script that deletes ~/.nix-profile so that I can’t use it, because otherwise things would collect in there that I would come to depend on, forget to update, and be stuck without if I rebuilt my system from scratch.

5 Likes

Thanks for the replies. So as I understand it, many of you do not use nix-env to install software? What about “unFree” things like Google Chrome (which is my preferred browser)? Can those things be installed via configuration.nix along with the normal free stuff?

I appreciate your patience in answering my questions. I’m a long time Linux user but NixOS is a different animal entirely LOL.

The suggestion to create a separate file for packages makes a lot of sense to me.

Can those things be installed via configuration.nix along with the normal free stuff?

Yup! You just have to set an option in configuration.nix. I think it’s nixpkgs.config.allowUnfree = true.

qyliss ok, thanks. I added that line but to actually install using nix-env I had to use NIXPKGS_ALLOW_UNFREE=1 nix-env -i to get them to install, so I assumed it wouldn’t work automatically via a nixos-rebuild.

I suppose I assumed incorrectly. I’ll give it a try.

In your configuration.nix, you can allow all unfree packages with

nixpkgs.config.allowUnfree = true;

or allow specific packages with

nixpkgs.config.allowUnfreePredicate = (pkg: builtins.elem (builtins.parseDrvName pkg.name).name
  [
    "chromium"
  ]);

. You also need to add the package in environment.systemPackages.

3 Likes

Ok, I’m listing stuff in configuration.nix and attempting to rebuild, but it keeps saying that cheese is an undefined variable. I keep looking at this and don’t see anything wrong, but perhaps I’m missing something obvious?

# List packages installed in system profile. To search, run:
  # $ nix search wget
 environment.systemPackages = with pkgs; [
   wget nano mc vlc ffmpeg gstreamer libdvdcss hplip git libreoffice handbrake pavucontrol gimp-with-plugins neofetch thunderbird transmission virtualbox weechat google-chrome skypeforlinux cheese ];

Some packages are organised in separate sets, so they don’t pollute the root namespace.

In this case, cheese is supposed to be gnome3.cheese. You can find this out on this site or by running nix search cheese.

2 Likes

erictapen thank you! I saw that gnome3 prefix but didn’t realize it needed to be part of the name listed in configuration.nix.

I appreciate the help. I’m learning.

Yep, that did the trick

Oh, I didn’t know about allowUnfreePredicate. That’s really useful!

1 Like

I still wish nix-env was gone and we had a simple nix install command to add a package to project/home/system Nix file. In addition, having a lock file that pins nixpkgs, again for project/home/nix.

Currently I’m using /etc/nixos/configuration.nix for anything that is needed to get a working system and a practical environment for root. I use home-manager for most other packages and configuration. Lastly I use direnv with shell.nix for project specific dependencies.

I still find the workflow a bit awkward, but regardless I’m using vim or vscode to edit these files and then rebuild the environment. For project files it rebuilds the environment automatically by direnv which is pretty cool.

2 Likes

If you are an Emacs userperhaps you’ll like to put config in org-mode and sudo tangle to the right place so with a simple backup of your home/your datas you can also replicate the system that enable you to use those datas

Or let Nix do it™ :wink:

1 Like

A nice simple solution that would cover this use-case would just be to have an /etc/nixos/pkgs.json that was imported into configuration.nix. Then it would be pretty straightforward to write a tool that could add/remove JSON entries in that file. Would be a nice start, and an improvement over nix-env, IMO.

Could even have per-user files that were included in the user configuration.

2 Likes

There are certain uses for nix-env -i. For example, I use it on my NixOps-managed machines because running non-installed programs with nix-shell quickly becomes annoying, and rebuilding the entire NixOps network just to have something like telnet or iftop available for quick inspection is overkill.

2 Likes

I’d say that rebuilding the networking feeling like overkill is a deficiency of NixOps rather than a good reason for nix-env.

The main use I see for nix-env is systems that serve two (or more) people who each want to manage their installed software in isolation from one another (But, those people could do it declaratively with home-manager). Since I don’t have a system like that that I manage, I also try to avoid using nix-env and channels too.

Thanks for the tip!

2 Likes