Standardization & Documentation of Package Compilation Options

[WillPower3309]

Issue description

As it stands right now, the nix package compilation options are not consistent, and not always clear. An example of the consistency issue is in compiling a package with x11. We currently have x11Support as well as withX. Gtk takes this to the next level, with packages using any variation of: withGtk gtkSupport withGtk2 gtk2Support withGtk3 gtk3Support gtk2 gtk3 (although granted some of these are gtk2 vs gtk3 options, point being that they could all be encompassed with either gtk2 or gtk3).

This change is one that is needed in order to not only improve the life of users managing packages and using overlays, but also one that is needed as a prerequisite to many other changes that are currently wanted for nix. With standardization of package compilation options, the nix query-options command could be worked on, and discoverability of these options would become incredibly simple, and make writing overlays that override any of these options a breeze. The current system of needing to investigate the package source in nixpkgs to find which options are available is incredibly inefficient, and standardizing these options is a great first step in addressing this problem.

As linked above, the nix query-options command could also provide a brief description of what the package compilation options do, so if this issue is worked on with the intention of working on that command in the future, we will need to incorporate a sort of compilation option system that defines all of the options commonly available to packages and a description of those options, which individual packages would then reference. This would somewhat resemble gentoo's use flag index, and could have an accompanying nix wiki page.

[WillPower3309]

If this is a change that is deemed wanted and relatively simple, I would be happy to look into it given a small push in the right direction of what would be needed

[rnhmjoj]

I don't think the inconsistencies like withSomething vs somethingSupport are the issue. The real problem is that there is no way to tell which arguments are options, the reason why you still have to view the source to discover them. I've seen two proposal so far:

1. Bringing back nixpkgs.config by defining shared options like pulseaudioSupport, guiSupport that affect all packages and possibly by defining all options through it.
2. Making packages modules, instead of plain functions. This way a package can export its options in a discoverable and customisable way, exactly like in NixOS.

Both will be a monumental effort: literally tens of thousands of packages needs to be changed (only counting Nixpkgs). Option 2 will also likely be a breaking change to be implemented in Nix, so you can imagine it will be more challenging.

I don't know what's the status of option 2, but option 1 stalled. Since this is a big deal, any attempts at solving it should really go through an RFC process: spread the word among maintainers, gather consensus, plan an execution strategy, etc.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[Aleksanaa]

Still important.

[WillPower3309]

Relevant: https://discourse.nixos.org/t/working-group-member-search-module-system-for-packages/26574

Looks like work is being planned for a modules like system. Could be a great chance for some standardization