The main purpose of this repository is to provide a central location for the common configurations I typically apply to my systems. Though I do not keep all of my configurations in this common location see Common vs Local Configuration.
Given that a lot of my common configurations live here I felt like it made sense to have some level of testing of my configurations so I can quickly iterate on my configurations and easily test my configurations against the latest changes in Nixpkgs. See Testing.
Testing my configurations would require building and running virtual systems based on the common configurations. Given that that work for building my configurations was already being done, the builds are cached for my systems to use to avoid rebuilding. See Caching.
This repository also provides some tools for managing local configurations. See Local Configuration.
So, in deviating from the standard NixOS config I might introduce issues into my system threw untested paths.
One of this such paths is how my systems are build and what version of tools are used when.
So in the typical nixos system, the currently running system provided
nixos-rebuild
and that system was built the last time nixos-rebuild
was
used to rebuild the system. So if the <nixpkgs>
is updated and then the
system is updated then the system is built using a nixos-rebuild
from the
previous build but using the next <nixpkgs>
. This means system being switched
into could have a very different nixos-rebuild
.
This is the standard practice and thus most tested/used.
So if we used only one version for nixos-rebuild
and the nixpkgs
used to
build the next system then we will not use the current system’s nixos-rebuild
to build the next system. Instead we will be using the next system’s
nixos-rebuild
to build the next system.
I local repos we can have the development shell use a separately pinned nixpkgs
than the nixpkgs
for the next build. The local shell will get its
nixos-rebuild
from the the pinned nixpkgs (falling back to another nixpkgs if
its not available, maybe the next nixpkgs
). Then nixos-rebuild
and be
wrapped to take whatever nixpkgs was used to update the pin after
nixos-rebuild
builds a new system.
Problems
nixos-rebuild
Instead of using nixos-rebuild
from next nixpkgs
, use the nixos-rebuild
from the currently running system.
Problems
nixos-rebuild
is not needed in normal usage of system.nixpkgs
Have the system provide a nixpkgs locally and use it to build nixos-rebuild
is
system dev shell.
Problems
nixpkgs
pinHave the system provide all the information to purely retrieve the nixpkgs
used to build it’s self.
Problems
nixpkgs
.When the system is built we put nixos-rebuild
in the next system’s
/run/current-system/
by using system.extraDependencies
and don’t include it
in system packages with system.disableInstallerTools = true
. When the build
shell can wrap the mutable path /run/current-system/bin/nixos-rebuild
This is good because it does not pin the nixpkgs
that built it, but it also
does not add to the list of things that need to be downloaded to change the
config.
system.includeBuildDependencies system.copySystemConfiguration
system.extraDependencies