Naming optional features and dependencies in nixpkgs: enableFoo, useFoo, withFoo, supportFoo, fooSupport, or...?

In nixpkgs, optional features and such are usually specified as a boolean parameter.
They are sometimes withFoo, or enableFoo, or something else. The question is: how they are named?

It would be marvelous to me if there were one and only one naming scheme for such options, but it might be just impossible. Documented criteria for naming in somewhere that is easy to find will be very helpful for newcomers, as the status quo is confusing a bit.

1 Like

I agree. I find fooSupport to be my personal preference, but as long as it is consistent it would be a big step up from where we’re at :+1:

1 Like

I think the best user experience is to have all but the most heavyweight dependencies on by default and then have disableX ? false parameters. Then people who don’t care about the size of their closures can get the full experience with one option and people who care about optimizing and don’t mind recompiling can look into the options.

1 Like

It seems to make sense, although if I could do bikeshedding I prefer enableX ? true to disableX ? false as “I enable X” is clearer than “I do not disable X”, but it is a detail at all.

Update: ah, I now understand what you meant. Yeah, naming aside ;-), it may be great to have a flag that works like IUSE='-* (...)' in Gentoo Linux.

1 Like

It’s not that great of a format, sorry, but here’s a presentation arguing for always defaulting to false:

I did not know about this presentation. Thank you for sharing!