How to use Nix to declare a traditional system?

The workflow I would imagine with these aims would be:

  • Installation
    • Already in Nixpkgs: install it
    • Just builds and runs with a simple package imitating existing packages for similar build systems: well, good, maybe submit it at some point
    • Complicated stuff: buildFHSUserEnv or some isolation solution (is basically makes a buildEnv then bind-mounts it to /usr/); to see later whether patching it to work with our path layout is worth the effort.
  • Configuration
    • Configuration or path to configuration passed on the command line anyway: scripts/config files under version control
    • Really wants configuration at specific paths: symlinks from those places to out-of-store VCS-managed directory, may need to be generated via Nix (but content updates need no rebuilds)
  • Configuration management improvements when stablising:
    • Simply runCommand to inject store paths into config (where relevant) or adding fixed-path symlinks to all you need to mention in configuration
    • Basic templating of paths and parameters
    • RFC42-style full generation

Note that a moderately hacky installation doable via Nix can usually be used across updates with not too much hurry trying to improve it; configuration leaving in a separate repository and simply symlinked as needed could even be called a best practice for some software under some circumstances for some people.

1 Like