Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flake-utils-plus as a base #270

Closed
Pacman99 opened this issue May 1, 2021 · 2 comments
Closed

Flake-utils-plus as a base #270

Pacman99 opened this issue May 1, 2021 · 2 comments

Comments

@Pacman99
Copy link
Member

Pacman99 commented May 1, 2021

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!

@Pacman99 Pacman99 pinned this issue May 2, 2021
@blaggacao
Copy link
Contributor

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? 😉)

@Pacman99 Pacman99 unpinned this issue May 15, 2021
@blaggacao
Copy link
Contributor

Immediate goal achieved.
👏 👏 👏 👏 👏 👏 👏
🍸 🍸 🍸 🍸 🍸 🍸 🍸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants