Alyssa's collection of Nix expressions
git clone git clone
Log | Files | Refs | README | LICENSE

README (3521B)

      1                         ===================
      2                         Alyssa's collection
      3                         of Nix expressions.
      4                         ===================
      6 This is a large collection of Nix expressions.
      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.
     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.
     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.
     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.
     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.