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 abuildEnv
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
- Simply
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.