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

Feature: NixOS Options #885

Open
Lyndeno opened this issue Mar 9, 2024 · 4 comments
Open

Feature: NixOS Options #885

Lyndeno opened this issue Mar 9, 2024 · 4 comments

Comments

@Lyndeno
Copy link
Contributor

Lyndeno commented Mar 9, 2024

Instead of importing individual configs, import a single modules that enables something along the lines of setting options in hardware.nixos-hardware or similar.

This would play nicer with some situations such as me wanting to use specializations with different hardware support than the default config. If I inherit the default config, I currently cannot easily disable one hardware import and use another. For example, having a specialization that enables nvidia optimus while the default config disables the nvidia card.

Of course, maybe there is a reason it is currently the way it is, and I am not aware?

@Lyndeno
Copy link
Contributor Author

Lyndeno commented Mar 9, 2024

This would make it cleaner to add optionals to hardware configs. I could optionally have an opencl setting for a laptop with an enable option. Without importing another module.

@Lyndeno Lyndeno changed the title Feature: NixOS Modules Feature: NixOS Options Mar 9, 2024
@Mic92
Copy link
Member

Mic92 commented Mar 25, 2024

Of course, maybe there is a reason it is currently the way it is, and I am not aware?

We have a wide range of hardware in nixos-hardware with sometimes only 0-2 people that are available to test a particular hardware. As such I think it's a good strategy to avoid too many abstractions and instead make hardware profiles independent from each other so that we can test and change it without breaking different profiles. However feel free to modularize a particular model with more options if you feel that the current structure forces you to use options that you don't want to use. I think this is an independent feature from merging all modules into one namespace.

@techieAgnostic
Copy link

Id like to express want for something like this, even if it is only the .enable option for each module.

As a use-case, a flake that is supporting multiple pieces of hardware, may very likely have a module similar to this:

{ lib, pkgs, config, inputs, ... }:
with lib;                      
let
  cfg = config.foo.hardware.framework;
in {

  imports = [
    inputs.nixos-hardware.nixosModules.framework-12th-gen-intel
  ];

  options.foo.hardware.framework = {
    enable = mkEnableOption "default framework options";
  };

  config = mkIf cfg.enable {
    <some other default framework configuration>
  };
}

With the intention being to set some default configuration in addition to the contents of the nixos-hardware module.

The downside to this is that you cannot gate the import of nixos-hardware, and so it gets included in every configuration when the flakes module list is loaded, which is exasperated for every other piece of hardware in the flake.

The work around to this is to import nixos-hardware directly in each nixosConfiguration, which means you cannot group it logically with the rest of the hardware configuration.

Giving each module an enable option would allow this usecase to work.

@Lyndeno
Copy link
Contributor Author

Lyndeno commented Mar 27, 2024

Write now I use disabledModules for my specialisations, but it feels gross

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

3 participants