Scope of Ordenada

[minikN]

We already talked about this, currently, home-manager is implicitly required in order to use ordenada. This got me thinking about ordenadas scope.

I don't think there is a right or wrong answer in terms of how much ordenada should cover, to me it seems like an opinionated question.

I think it would be nice to remove HM as an implicit requirement. Especially because ordenada has HM in its inputs as well. I don't know the technical reason that is just yet because I'm still scratching the surface.

But regardless, a user can always use HM for certain things if they want to, and I totally don't want Ordenada to be a wrapper around every nixos/HM option. But I think it can cover more than it currently does.

For example, we could add a kernel module, that comes with sane defaults and makes it easier to set options like

boot.kernelModules = [ "kvm-intel" ];
      boot.kernelPackages = pkgs.linuxPackagesFor pkgs.linux_latest;

      hardware.enableRedistributableFirmware = true;
      hardware.cpu.intel.updateMicrocode = true

Another thing would be the nixos-hardware module. How about we integrate it to Ordenada? We could create a system module (the counterpart to home module) that has an option hardwareProfile, that can be set to a string, like lenovo-thinkpad-t460, if set, ordenada will use the nixos-hardware module to apply the config for

nixos-hardware.nixosModules.lenovo-thinkpad-t460

That wat the user doesn't even need the nixos-hardware module (but ofc can if they wanted), but can still benefit from it if they use ordenada.

Again, maybe this is a wrong approach for valid reasons I'm not aware of. Happy to discuss it.

[migalmoreno]

Making Home Manager's dependency implicit isn't ideal, I agree, so I've gone ahead and imported its list of modules in ee15fb8 so you don't have to import them in your configuration anymore. This will cause a build time error if users also have the HM modules imported in their configs, so we could try to add an assertion in ordenada.features.home in the future to not catch anyone by surprise. However, I think it should be assumed that users who decide to use Ordenada should let it take care of HM's installation/setup for them, but this won't take away the power to still use its modules/options, so you can keep all your home-manager.users.example-module configs outside of the Ordenada config.

Now, in regards to scoping, my initial plan for Ordenada was to simply be a wrapper config around some NixOS/HM utilities in the same vein as RDE with Guix/Guix Home, but as I kept expanding the list of features, I realized that there were third party modules/libs that made no sense for the user to have to install/setup themselves. Themeing is a great example that comes to my mind, in RDE there were no themeing utilities provided OOTB and I had to resort to a third party channel (farg) to have a uniform colorscheme across WMs/bar/etc. Integrating arkenfox-nixos into the Ordenada Firefox feature also made a lot of sense, and users can already specify its settings (via ordenada.features.firefox.arkenfoxSettings) without having to set up the module.

In Ordenada, I wanted to make themeing a first-class citizen and we're currently making use of third party modules (nix-rice and base16.nix) to control the style of every module that has UI settings. Users are able to change the global themes with the ordenada.features.theme feature and if they want to configure the colorscheme of an application that has no Ordenada feature yet with the same theme, they can simply use config.ordenada.features.theme.scheme to grab the current theme colors. For even greater customization, Ordenada's overlays are extended with base16's overlays so users can also use their utility functions (via pkgs.lib.ordenada.base16) without having to manually set them up (we could also extend them with nix-rice's and other modules in the future ofc).

I agree that it would be great to have Ordenada features to set kernel configurations, file systems, network settings, essentially replicating RDE's system features, my plan was to do it progressively while I found valid and generic use cases like the ones you mentioned. In regards to the hardware profile example, yes that can be part of the aforementioned system features, but I'd rather not couple particular hardware names to nixos-hardware modules in Ordenada code. As you mentioned, since we can import the nixos-hardware modules ourselves (like we now do for HM ones), we could expose the entire nixos-hardware.nixosModules under an option (e.g. ordenada.features.system.defaultProfiles so users can use it like this:

ordenada.features.system.profiles = with ordenada.features.system.defaultProfiles; [ 
  lenovo-thinkpad-t460 
  anotherHwProfile
];

This way users can apply arbitrary hardware profiles without having to set up their modules one by one. Additionally, we could perhaps even apply "automatic" hardware profiles as the default value for the above option based on the current device.

In general, I think we should move in that direction: import everything that Ordenada itself uses so users don't have to install those modules implicitly and expose applicable options/overlays/etc where it makes sense so users can more easily extend Ordenada without having to modify its codebase.