You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-plus systemFlake 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 revamped evalArgs, which is the mkFlake 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
profiles and suites (collections)
auto testing of all profiles and hosts
auto-importing — this can be done in fup but I don't think it can be done as well
ex: hosts = lib.mkMerge [ (devos.lib.importHosts ./hosts) { NixOS.system = "aarch64-linux"; } ]; This is only possible due to evalArgs use of the module system
usage of module system which brings type checking and incredibly powerful abilities as demonstrated above. Also allows API to be auto documented and easily changed — module system option deprecation is really straightforward
custom builds, like isoConfig and home-manager only buillds
integrated home-manager and deploy-rs support: all users/hosts are wired up into relevant outputs
many more, now that we have a stable API and internal code base there is lots of room for new features
We'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!
The text was updated successfully, but these errors were encountered:
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? 😉)
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
ex:
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!
The text was updated successfully, but these errors were encountered: