1 =================== 2 Alyssa's collection 3 of Nix expressions. 4 =================== 5 6 This is a large collection of Nix expressions. 7 8 The primary way to use the expressions is by applying a profile to a 9 NixOS or nix-darwin system. See the sys directory for available 10 profiles. A profile can be installed on a system using the `activate' 11 script. 12 13 These profiles are structured in a way that is very different to NixOS 14 configurations in several respects. First, rather than setting NIX_PATH 15 to a mutable tree, these profiles copy the tree into the Nix store at 16 build time, then set NIX_PATH to point to that. This means that 17 angle-bracket path syntax (e.g. <nixpkgs>) points to exactly the 18 expression that it pointed to when the system was built. To use a 19 mutable working tree in Nix expressions, relative or absolute paths can 20 be used instead. Another advantage of doing things this way is that the 21 Nix expressions used to build a given system can always be recovered 22 from the Nix store, since they will be a dependency of the system 23 derivation. 24 25 Whereas NixOS configurations are typically made up of configuration 26 files along with seperate repositories or channels for Nixpkgs (and 27 possibly some overlays), here a single tree is used. This means that 28 version control history will always be able to identify which version 29 of Nixpkgs is compatible with which version of the configuration files, 30 while also allowing custom downstream changes to be made to Nixpkgs. 31 No other approach provides both of these features in such a convenient 32 way. With the exception of some custom modifications, any upstream 33 trees (Nixpkgs, various overlays) are left intact in the tree, for ease 34 of patch generation against those upstream trees. The structure of the 35 tree is deliberately designed so that it can be used as a single entry 36 in a NIX_PATH. <nixpkgs> will automatically point to the nixpkgs 37 subdirectory, and it will automatically load the overlays in the 38 nixpkgs-overlays subdirectory through <nixpkgs-overlays>. Other 39 structures would be possible, but only this one has this feature, and so 40 it made sense to choose it. 41 42 In constrast to NixOS, an attempt is made here to assist with per-user 43 application state management through the `home' and `xdg' modules. The 44 `xdg' module allows creating an immutable XDG_CONFIG_HOME in 45 /run/current-system, which allows environment.etc-like management of 46 per-user configuration files, without introducing a new, seperate build 47 command à la home-manager. The disadvantage to this approach is that, 48 unlike home-manager, it assumes that the user has permission to rebuild 49 the entire NixOS system. The `home' module allows activation scripts to 50 be defined on a per-directory basis inside a user's home. For programs 51 like gpg, which require configuration files to be in the same directory 52 as mutable program state, this approach allows configuration to be 53 stored read-only in the Nix store, and then symlinked into the state 54 directory, allowing this type of program to still realise some of the 55 benefits of Nix-based configuration. 56 57 Note: MIT license does not apply to the packages built by Nixpkgs, 58 merely to the package descriptions (Nix expressions, build scripts, and 59 so on). It also might not apply to patches included in the tree, which 60 may be derivative works of the packages to which they apply. The 61 aforementioned artifacts are all covered by the licenses of the 62 respective packages.