Pinning OS configuration in the configuration.nix instead of outside

[CMCDragonkai]

In the future, instead pin it in the configuration.nix. Instead of using the /nix/nixpkgs. Because it makes more sense. We pin the OS package set. Note that for changes to the OS, you can install packages without affecting the OS. But if you are making changes to the OS. A better way is overlays, or changing some aspect of pkgs. There's probably a way to override this. Best to find out.

This makes the OS configuration more self-contained in its determinism.

[CMCDragonkai]

• https://nixos.wiki/wiki/NixOS_Modules
• https://github.com/NixOS/nixos/blob/master/lib/eval-config.nix

The main issue is that the configuration.nix tends to receive parameters. What happens to those parameters if we try to make the configuration.nix self contained?

[CMCDragonkai]

The following builtin functions are new or extended:

builtins.fetchGit allows Git repositories to be fetched at evaluation time. Thus it differs from the fetchgit function in Nixpkgs, which fetches at build time and cannot be used to fetch Nix expressions during evaluation. A typical use case is to import external NixOS modules from your configuration, e.g.

imports = [ (builtins.fetchGit https://github.com/edolstra/dwarffs + "/module.nix") ]; Similarly, builtins.fetchMercurial allows you to fetch Mercurial repositories.

builtins.path generalises builtins.filterSource and path literals (e.g. ./foo). It allows specifying a store path name that differs from the source path name (e.g. builtins.path { path = ./foo; name = "bar"; }) and also supports filtering out unwanted files.

builtins.fetchurl and builtins.fetchTarball now support sha256 and name attributes.

[CMCDragonkai]

One issue is that if the version is pinned inside the configuration.nix, this version is not exposed to the underlying environment for nix-env and eventually nix 2.0. If we think of environments as hierarchal shells. The OS environment should be inherited by the profile environment, and subsequently by the shell environments. So an appropriate NixOS configuration if it pinned the configuration within itself, it should then provide that pinning environment for the config.nix. One way to do this is through the setting of <nixpkgs> in the nixPath. That is to set it to a URI that points to some location that is guaranteed to be the nixpkgs.

Suppose by pinning in configuration.nix, that you later actually acquire the store path for nixpkgs, then you can just provide that same store path into the <nixpkgs>.

The only thing missing is dealing with overrides or overlays, how do they get inherited? I read some issue where it was problematic for the shell.nix to access overrides/overlays specified in config.nix, because they are separately evaluated. It seems it would make sense if the shell.nix could "import" the config.nix" and that could "import" theconfiguraiton.nix`.

[CMCDragonkai]

This is now done: https://gitlab.com/MatrixAI/Platforms