Extract custom system builds from devosSystem out of lib

[Pacman99]

Describe the solution you'd like

There should be some way for users to add and edit their own custom system builds for all hosts like what is currently being done for isoConfig and in the future hmConfig.

Describe alternatives you've considered

Edit lib/devos/devosSystem.nix. But optimally the end user shouldn't have to edit a lib function.

Additional context

I think this could be done as a file that defines an attrset mapping builds to nixosSystem's(or darwinSystems, homeConfigurations, robotnixConfigurations). And all builds will be available under config.system.builds as is currently being done.

related: #168

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[nrdxp]

The reason lib.devos.<functions> aren't exported into the global lib, is that they should continue to be reduced until ideally non-existent, or close. This is why I'm trying to focus mainly on #152, and at least get a solid PR out with a good start.

[Pacman99]

To be clear I'm not saying change the location of devosSystem. I just want to extract out the isoConfig within it to a file that users can easily find and edit and document that. So a user can change the isoConfig or add their own custom system builds.

[blaggacao]

I think this can be tackled now, I don't plan to play with isoConfig for the next couple of days.

[Pacman99]

I'm not yet sure how to go about doing this. I think an important question to answer is, should there be a user facing api for adding custom builds? If we decide against that, this would just involve adding a few more files to lib to extract the code.

[blaggacao]

I think we should start by splitting, then maybe we could get a clearer picture if we need a user facing API. I also think if #91 is implemented, at least a user facing api within that same file hierarchy would be quite ok, since then a rebase would become cheap, also for nix flake template users, even if code is somewhat mixed together.

[blaggacao]

We might include exposure to the .builder fup arg in api-next to satisfy this use case and be able to close this issue.

[Pacman99]

If you do set the .builder arg then you would overwrite the the iso and homes builds since you would overwrite devosSystem. Either way I'm going to close this since those modules have been moved to lib.modules, and adding new custom builds is very straightforward - add a couple llines to devosSystem and add a module to lib.modules. And after some thinking, I just can't see a way for this to be done outside of devosSystem, so I don't actually think its possible to do any more extraction.

[Pacman99]

Reopening, I realized that the list of modules is available in nixos as a module arg, so we might be able to write isoConfig as a module. And mkHomeConfigurations might be able to do all the work of setting up standalone home-manager configurations.

So it might actually be possible to obsolete devosSystem entirely.

[Pacman99]

implemented in #266