Thank you for the review, @drupol. Of course, this is not motivated by need. This is a drive-by PR motivated by my usage of this nix option. Fits in the "nice to have" category. Nix configuration options don't change frequently, so I think we can afford to include options for all of them. But that's obviously not what is implemented here.

Thank you for the review, @drupol. Of course, this is not motivated by need. This is a drive-by PR motivated by my usage of this nix option. Fits in the "nice to have" category. Nix configuration options don't change frequently, so I think we can afford to include options for all of them. But that's obviously not what is implemented here.

Why is it nice to have? What is the use-case in NixOS over just using the system-features option?

TLDR; I wanted to let the readers of nix.settings.system-features documentation know of extra-system-features and then I took that a step further and created nix.settings.extra-system-features.

Providing a value for nix.settings.system-features overrides its default option value, which is currently a list of several features. To merely add to that list, one can provide the addition features as the value of nix.settings.extra-system-features. To be clear, these are passed to Nix in its configuration file with no further processing. It is Nix that puts the extra ones on top of the base ones.

So, the value of the extra-system-features in NixOS is similar to the upstream Nix option that it represents; being able to merely add on top of system-features. Although I'm not sure what the upstream default value for system-features is.

But that value is already provided by this NixOS module, because nix.settings is freeform. I'm already using nix.settings.extra-system-features myself and I imagine others do, as well. The value suggested by this PR is type checking and documentation. In particular, a user who reads the documentation for nix.settings.system-features and does not know of the existence of the upstream extra-system-features might assume that the only way to add additional features is to do:

nix.settings.system-features = [
  "<explicitly provide>"
  "<the default features>"
  "add-some-feature"
];

which carries the risk of missing out on future default features.

This PR adds a documentation reference from nix.settings.system-features to nix.settings.extra-system-features.

TLDR; I wanted to let the readers of nix.settings.system-features documentation know of extra-system-features and then I took that a step further and created nix.settings.extra-system-features.

Providing a value for nix.settings.system-features overrides its default option value, which is currently a list of several features. To merely add to that list, one can provide the addition features as the value of nix.settings.extra-system-features. To be clear, these are passed to Nix in its configuration file with no further processing. It is Nix that puts the extra ones on top of the base ones.

So, the value of the extra-system-features in NixOS is similar to the upstream Nix option that it represents; being able to merely add on top of system-features. Although I'm not sure what the upstream default value for system-features is.

But that value is already provided by this NixOS module, because nix.settings is freeform. I'm already using nix.settings.extra-system-features myself and I imagine others do, as well. The value suggested by this PR is type checking and documentation. In particular, a user who reads the documentation for nix.settings.system-features and does not know of the existence of the upstream extra-system-features might assume that the only way to add additional features is to do:

nix.settings.system-features = [
  "<explicitly provide>"
  "<the default features>"
  "add-some-feature"
];

which carries the risk of missing out on future default features.

This PR adds a documentation reference from nix.settings.system-features to nix.settings.extra-system-features.

That reasoning didn't came across when reading the current description. As of now we define both options and it's unclear which one is the right one to use for which use-case. However I am wondering if we should not instead move the default from lib.mkOption to config so that users only need to set to nix.settings.system-features without having to re-set the existing features defined by the default.

Looks like this is what did this before but it got removed by @ck3d https://github.com/NixOS/nixpkgs/pull/372878/files

@ck3d your intent from the pull request doesn't seem to match up with the change you did:

Assign default for option system-features at the common place. It allows use to re-use the default value in cause of setting the option.

The former behavior merged existing system-features but now this no longer the case.

Alternative fix #383052