Naming convention for optional feature flags #148730
Description
Generally, Nixpkgs exports flexibility of upstream build system with boolean
flags to corresponding Nix expression, so, for example, Nix expression for
doas(8) starts with following:
{ lib, stdenv, fetchFromGitHub, bison, pam
, withPAM ? true, withTimestamp ? true }:
There are least two ways to represent the fact that particular input is
optional:
- Add boolean flag like
withPAMin example above, and use include dependency
with something likebuildInputs = lib.optional withPAM pam; - Write code to handle input beeing null instead of derivation, with code like
configureFlags = lib.enableFeature (pam != null) "pam".
In cases when upstream build system provides option to enable or disable
functionality that is not tied to external dependency, only boolean flags
approach is possibly; probably this is why it is more popular.
Furthermore, we don't have convention for naming of this flags. Across the
tree, we have "withPAM", "withPAMSupport", "enablePAM" and "usePAM". The same
mess happens for every other flag. You can get idea with something as simple as
$ git grep -i PAM | grep -iE 'with|support|enable|disable'
Substitute PAM with systemd, nls, ssl or alsa.
This inconsistency, among other things, makes writing overlays harder. On
Gentoo, if you wan't whole system without, e.g NLS, you just set global USE
flag and rebuild the world.
On Nix, you can do the same -- you create overlay, but you need to setup 3 or 4
flags, each of them controlling some irregular subset of all packages. This is
not nice user interface, even (especially?) when user is a developer. I
propose that we make things uniform.
Currently, "supportFoo" seems to be the most common convention, used both for
external dependencies and optional internal features, so the simplest solution
would be to convert all enable/with/disable to this convention. Regular
expression can do it with reasonable accuracy.
Alternatively, and what I would prefer instead, is to follow autoconf
convention: --with for external dependencies, --enable for internal. It
involves more work, more changes, and, unlike previous approach, can't be done
tree-wide.
No matter which of these paths we agree on, I am willing to provide patches for
Nix expressions, nixpkgs manual and probably to nixpkgs-hammering.