Motivation for this change

Prepare for a decentralized future with flakes, where modules will need to adapt to their neighbors, about which those modules can not make too many assumptions. Supporting two releases of NixOS may be impossible at times for flakes if they can't read the options variable.

Additionally, this provides a partial solutions to the expression problem as applied to separately distributed modules.

Feature interactions: where to get the code?

               Core features     Feature A

Core features  nixpkgs/nixos     Flake A

Feature B      Flake B           ???

Without this feature, ??? will always have to be a separate module that users have to turn on manually to make the interaction between Feature A and Feature B not break.

With this feature, ??? can be packaged by either Flake A or Flake B, ensuring that the interaction between the features is always dealt with.

Things done

• Used this in a real-life separately distributed NixOS module
• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.