NixOS modules and configurations offer us a tantalizing way to express and share systems. My friends and I can publish our own flakes containing nixosModules
and/or nixosConfigurations
outputs which can be imported, reused, and remixed. When it comes to secret projects though, that openness and ease of sharing can be a bit of a problem.
Let’s pretend my friend wants to share a secret NixOS module or package with me, they’ve already given me access to the GitHub repository, and now I need to add it to my flake. My flake is public and has downstream users. I can’t just up and add it as an input. For one thing, it’d break everything downstream. More importantly, my friend asked me not to.
It’s terribly inconvenient to add the project as an input and be careful to never commit that change to the repository. Worse, if I did screw up and commit it, my friend might be disappointed in me. We just can’t have that.
Let’s explore how to create a flake which extends some existing flake, a pattern which can be combined with a git+ssh
flake URL to resolve this precarious situation.
This same situation strategy can be applied to other outputs of a flake, and can be combined with nixpkgs.lib.makeOverridable
.
Extending a Flake
Let’s assume for a moment we have a simple flake called original
with a nixosConfiguration
and a nixosModule
:
While our little demo configuration, teapot
, might not be a very practical system for hardware (or even a VM) it’s a perfectly valid NixOS expression which we can build and inspect the resultant output filesystem of:
Now, let’s assume there exists some other flake, called extension
that looks like this:
Our goal is to create a teapot
with the extension.nixosModules.default
module included.
To do that, we’ll create a new flake, called extended
which looks like this:
Because of outputs = { self, nixpkgs, original, extension }: original.outputs // { /* ... */ }
this extended
flake has the same outputs of original
, plus whatever overrides we add inside { /* ... */ }
.
We call extendModules
on the original nixosConfiguration.teapot
to extend the configuration with new modules, in this case, our extension.nixosModules.default
.
Now we can inspect the resultant output filesystem:
Find out more about building Linux systems using Nix
Using private GitHub inputs in flakes
While the github:username/repository
flake paths utilize Github’s API and work well for public repositories, you may experience issues trying to use it with a private repository.
In these cases, try using the git+ssh
protocol. For example:
Running nix flake update
should then use your SSH key and work, as long as you have the ability to clone that repository over SSH.