Closed Pacman99 closed 3 years ago
Random excitement: This change also enables me to explore a venue for DevOS users to couple up with the kubernetes ecosystem via kubenix
to manage their personal environments (like a resilient and fault tolerant RPi plant watering cluster? :wink:)
Immediate goal achieved. :clap: :clap: :clap: :clap: :clap: :clap: :clap: :cocktail: :cocktail: :cocktail: :cocktail: :cocktail: :cocktail: :cocktail:
If you have been following changes in the develop branch, one of the most important changes that has been made in the past couple weeks is rebasing DevOS on flake-utils-plus. Here is the story of how that came to be, along with an announcement of the upcoming change.
Reasoning
DevOS started off as a template with various goals, including the ability to collect all your nix code in a clean and organized manner. In the past month or so, we have been preparing to also support DevOS's use as a library. Before we were willing to release a public API we had to improve our internal one.
There was a lot of logic in DevOS to deal with configuration building and flake output creation. Now that's not necessarily a bad thing, but those functions were extremely DevOS specific and had a poor API, making it hard to maintain. So the options were to either improve our own internal API or see if someone else had already done it for us.
flake-utils's
simpleFlake
and flake-utils-plussystemFlake
were extremely promising. The former didn't really fit well with DevOS (think puzzle pieces), and didn't have too much customizability.systemFlake
on the other hand was extremely low level, maintained the same restriction as flake-utils (no dependencies), was extremely customizable, and it could even do configuration generating. So we decided to go with that.Changes
To make the rebase on flake-utils-plus (fup) possible, changes were required in both DevOS and fup. So we started by contributing some overall improvements to fup to make configuration generators more general, improve output builders, and added some good exporters. Many of those changes made it into the 1.1.0 fup release. You can take a look at some of the discussion for that effort: gytis-ivaskevicius/flake-utils-plus#2
On the DevOS side there needed to be an API change to
mkFlake
so that it fit well with fup. The nice thing about the rebase is that it forced us to be disciplined with our API - consistent, general, and contained. That lead to a completely revampedevalArgs
, which is themkFlake
API. You can see it in action starting from DevOS 0.9.0.mkFlake
itself had to be redone, which ended up being a lot of fun — like blocks fitting together perfectly thanks to all of the prep work.Ecosystem
There have been suggestions to merge fup into DevOS, drop DevOS in favor of fup, or merge DevOS into fup. I'm going to pause with the storytelling and offer my opinion on that: both tools have a place in the flake ecosystem. There will be some people who decide that fup is the better tool for their use-case, and thats awesome. DevOS is here to add many more features that fup is not capable of, due to fup's stance on simplicity. We also want to maintain DevOS's original goal of offering up a template.
Devos features
hosts = lib.mkMerge [ (devos.lib.importHosts ./hosts) { NixOS.system = "aarch64-linux"; } ];
This is only possible due to evalArgs use of the module systemisoConfig
and home-manager only builldsWe'd love to hear more opinions on the matter. Why would you prefer to use one project over the other? What do you think of the new API (take a look at develop's flake.nix)? Anything else not mentioned. The more feedback we receive, the better the final product will be!