As we are now using Flakes for development on master the scope of this PR is much smaller than the original one.
It's only about adding Flakes support to NixOps, we are not touching the development workflow.
This PR adds flake support to NixOps, meaning that you can do things like
Currently evaluation is not as hermetic as we'd like since the NixOps-specific NixOS modules are provided impurely. Ideally, the flake would lock a particular version of the NixOps flake as input.
Likewise, NixOps needs to pass in the generated file physical.nix as an impure input. This is something of an inherent issue with the NixOps model. Maybe for flakes in local Git repositories, physical.nix could be auto-committed.
Copied PR body from #1202
As we are now using Flakes for development on master the scope of this PR is much smaller than the original one. It's only about adding Flakes support to NixOps, we are not touching the development workflow.
This PR adds flake support to NixOps, meaning that you can do things like
This will create an EC2 instance running Hydra, using exactly the configuration locked by
flake.lock.Currently evaluation is not as hermetic as we'd like since the NixOps-specific NixOS modules are provided impurely. Ideally, the flake would lock a particular version of the NixOps flake as input.
Likewise, NixOps needs to pass in the generated file
physical.nixas an impure input. This is something of an inherent issue with the NixOps model. Maybe for flakes in local Git repositories,physical.nixcould be auto-committed.