feat(bud): implement a 'cfg' command for managing profiles / users / hosts / modules

[90-008]

This add a cfg command to bud with following subcommands:

• cfg add: Fetch and add profiles / users / hosts / modules from other users' DevOS repositories
• cfg remove: Delete a profile / user / host / module from your configuration
• cfg show: Show the profiles / users / hosts / modules of a users' DevOS repository (or yours)

[nrdxp]

Anyone get a chance to test this? I'll try to take a look at it over the weekend if not.

[blaggacao]

This is not in any significant way related, but I'm starting to favor the folder layout that is exemplified in digga/examples/groupByConfig.

[danielphan2003]

Speaking of folder layout, here is mine based on digga's example groupByConfig:

├── home/
│   ├── modules/
│   ├── profiles/
│   ├── users/
│   └── default.nix
└── nixos/
    ├── hosts/
    ├── modules/
    ├── profiles/
    └── default.nix

This makes it easier to manage in flake as home = { ... } would simply be home = ./home, and so on.

[90-008]

It should be easy to support that layout; aside from nixos would need to be differentiated. Maybe nos an hm could refer to how it currently works (nos points to root, hm to users dir} and nixos home for the new layout. The tool could also do a check to see if nixos and home folders exist in root and act accordingly with the current "prefixes".

[Pacman99]

This is a neat idea to share profiles. I think we can brainstorm ways to let this concept work without requiring a strict folder layout, since many of us use non-standard repo formats. And if we do that it might make sense to merge this into upstream bud instead - assuming the only objection is that it requires a strict devos format.

I'm thinking mkFlake could output its evaluated config so that bud can analyze it and inspect where profiles/hosts are stored. Or we could create a list of possible places those files can be stored and check all(not a very dynamic approach).

We've had the discussion on sharing profiles before, we decided against a flake output because we weren't sure how share-able they are. I like this approach since we treat them as files/templates and let the user adapt them once their copied.

Also modules should be shared using nixosModules output and externalModules/modules options.

[90-008]

This is a neat idea to share profiles. I think we can brainstorm ways to let this concept work without requiring a strict folder layout, since many of us use non-standard repo formats. And if we do that it might make sense to merge this into upstream bud instead - assuming the only objection is that it requires a strict devos format.

I'm thinking mkFlake could output its evaluated config so that bud can analyze it and inspect where profiles/hosts are stored. Or we could create a list of possible places those files can be stored and check all(not a very dynamic approach).

We've had the discussion on sharing profiles before, we decided against a flake output because we weren't sure how share-able they are. I like this approach since we treat them as files/templates and let the user adapt them once their copied.

Also modules should be shared using nixosModules output and externalModules/modules options.

We can let the user specify any path they want seperated by dots, which would support all structures for copying at least. For seeing what modules / profiles etc. are available we can search for directories and let users define where their modules / profiles / hosts etc. are. (in a top level nix file?)

[blaggacao]

assuming the only objection is that it requires a strict devos format.

Correct. If we can generalize, that would be fantastic!!

@yusdacra I did not understand your reply. Sry :shrug:

[nrdxp]

Wouldn't the obvious solution to this be to simply export the profiles via an attribute set at outputs.profiles? Since we already build a profiles attribute set for suites, this should be really simple no?

[90-008]

Wouldn't the obvious solution to this be to simply export the profiles via an attribute set at outputs.profiles? Since we already build a profiles attribute set for suites, this should be really simple no?

That would work, but we'd need to process the nix flake show output. --json for flake show was merged recently, so we could use that. The reason I didn't want to do this is if we want to generalize it, we can't depend on stuff DevOS exposes. But it could also be useful to enforce it at bud level so there is some sort of standardazation across the configs.

[Pacman99]

Wouldn't the obvious solution to this be to simply export the profiles via an attribute set at outputs.profiles? Since we already build a profiles attribute set for suites, this should be really simple no?

I prefer something along the lines of this PR better. I'm against exporting profiles because they are not built to be shared. Sometimes they depend on other profiles or they use things which are devos specific, and I feel like flake outputs should be fairly generic.

This makes more sense since we're just copying the profiles over and that both allows and encourages the user to edit the profile for their needs and situation.

[nrdxp]

Seems hard to justify being against one but not the other since they are kinda the same :confused:

I was just trying to find a solution to the problem of having a rigid structure and flake outputs seem like the right solution. You can still copy the files from the outputs if you desire to modify them. Profiles are usually generic enough to be shared. Anything super idiosyncratic should probably be in your user profile or your host files.

In any case, we export profiles at work in bitte and it works out rather nicely.

[blaggacao]

I'd like to add, that in fluidattacks/makes, we started to use a special __makes__ json serializable output to let the purpose built cli (m) know about things.

If we implement well chosen cli wrappers (in bud) around devos or digga, I'd favor such approach.

It should be __digga__ to enable other tooling in future.

This is somewhat decoupled from the decision on what to export.

Maybe we can recompile a set of use cases & measure them by the initial & current goals of the sharing model, taking first principles into account?

@yusdacra sorry that your work is getting cought in such fundamentals. 😄

[90-008]

It's alright, no rush here :D

I like the idea of having a JSON output that bud can use. I'd say that a good approach could be to support a standardized structure there and let bud cfg utilize it as it's "first-class" support or whatever you'd call it. Since this would be implemented in digga, all flakes using it would work with bud cfg (if i'm understanding it right). Then, if there is no such output, bud cfg could fallback to just listing all files recursively, and do copying by path (similar to how this PR does it right now). This would allow it to be generalized while having better integration with flakes that use digga (or ones that just specify the JSON output manually).

I would be willing to rewrite this in Rust (I would like to keep it in bash as to keep it simple, but if JSON will come into play I much rather prefer serde than jq. And as more features are added, things are bound to get complex).

Offtopic note: something like the new flakes listing on search.nixos.org but for devos / digga repos would go hand in hand with this PR as users could easily find profiles / modules from bud itself.

[montchr]

despite #477, i think this would be a great enhancement, perhaps as a regular old devshell script