This RFC covers quite well how boolean options ought to be named, but other types are not considered and this design might thus interfere with future work. As such I’d like this discussion to at least look into the other types as to not squash future possibilities.
If we do go ahead with this prefix-based approach, what prefixes could we use for numbers, lists, and attribute sets?
(Example of an attribute config in nixpkgs: https://github.com/nixos/nixpkgs/blob/629dd2dd4c4eb53a43316043279696edf9f597f2/pkgs/development/mobile/androidenv/emulate-app.nix#L7-L15)
A problem I also see with the other types it is that is no good way to declare, document and enforce feature parameter types, unless we resort to using the module system.
Things I’d like added to the RFC:
- You MUST note the date / nixos version the deprecation happened in a comment, like in
aliases.nix
Questions I’d like see answered in this RFC or at least explored and listed for future work:
- If we do go ahead with this prefix-based approach, what prefixes COULD we use for numbers, lists, and attribute sets?
- How to we address bitrot? Should ofborg and/or nixpkgs-review build every combination of bool flags?
- Which configurations should be built on hydra and added to the cache? What are the criteria for considering additional configurations to be built?
- How should alternative configurations be added to the cache? See What is the right way to add optional pkgs to nixos binary cache?