Summary
This RFC proposes that most feature flags used as callPackage arguments in nixpkgs should consistently start with either enable or with.
These feature flags are boolean inputs controlling optional functionality (e.g. enableMPI, cudaSupport).
They are not new attributes or structural changes to derivations — only a naming and semantic convention to make overrides, readability, and tooling more consistent.
At the same time, we propose to migrate the legacy xxxSupport style (e.g. mpiSupport, cudaSupport) toward this unified form over time.
Motivation
Feature flags in nixpkgs have evolved organically, leading to a mix of naming patterns:
| Current examples |
Meaning |
mpiSupport |
Enable MPI integration |
pythonSupport |
Enable Python bindings |
enableMPI |
Enable MPI support |
useCuda |
Enable CUDA |
withTests |
Include tests |
This inconsistency causes real issues:
- Overrides are fragile — it’s unclear whether to set
mpiSupport or enableMPI.
- Code review is harder — flag semantics differ across packages.
- Tooling can’t detect flags — no consistent prefix pattern.
- New contributors guess — perpetuating inconsistent styles.
See #415208, where different packages use xxxSupport or enableXxx interchangeably for the same purpose.
Proposal
1. Unified naming rule
A feature flag — a boolean argument controlling optional build functionality — must start with one of the following prefixes:
enableXxx — turns on or off an optional feature or backend.
withXxx — includes or excludes auxiliary or additive components (tests, examples, docs).
All other forms (xxxSupport, useXxx, enableXxxSupport, etc.) are considered legacy.
2. Examples
| Before |
After |
mpiSupport |
enableMPI |
pythonSupport |
enablePython |
useCuda |
enableCuda |
enableCudaSupport |
enableCuda |
withDocs |
✅ unchanged |
withExamples |
✅ unchanged |
3. Guidelines
enableXxx → optional dependency or core feature toggle.
withXxx → optional additive component (tests, docs, examples).
- Avoid double prefixes/suffixes like
enableFooSupport.
- Do not use dependency names (
python = null) as feature flags.
- When refactoring, keep backward compatibility temporarily (alias + deprecation notice).
4. Scope
- Applies only to arguments passed to
callPackage, not to attributes inside derivations.
- No changes to
mkDerivation or the build system are required.
Short Comparison: enableXxx vs xxxSupport
| Aspect |
enableXxx |
xxxSupport |
| Explicitness |
✅ Verb form clearly expresses a boolean action. |
⚠️ Ambiguous — could be capability or value. |
| Consistency with NixOS options |
✅ Matches services.foo.enable. |
❌ Divergent naming pattern. |
| Discoverability |
✅ Easy to grep and lint (enable*). |
❌ Common “Support” suffix also used for other meanings. |
| Historical usage |
⚠️ Newer style, less common in legacy code. |
✅ Widely used in older HPC packages. |
| Tooling / automation |
✅ Simple to detect feature flags automatically. |
⚠️ Requires suffix-based heuristics. |
| Migration cost |
⚠️ Requires gradual adoption. |
✅ Already prevalent. |
Summary:
enableXxx is clearer, machine-friendly, and consistent with the broader Nix ecosystem.
xxxSupport dominates historically but is ambiguous and harder to reason about.
- Recommended direction: new code uses
enableXxx, while existing code can gradually migrate.
Migration Strategy
-
Document the convention in the nixpkgs style guide and contributor documentation.
- Encourage all new packages to use
enableXxx / withXxx.
- Mark
xxxSupport as a legacy pattern.
-
Perform a treewide replacement using codemods or scripted renames:
- Replace
xxxSupport → enableXxx when it clearly represents a boolean flag.
- Adjust call sites and overrides consistently.
- This can be automated incrementally, starting with leaf packages.
Benefits
- Unified, predictable convention across nixpkgs.
- Easier to write and maintain overrides and overlays.
- Consistent with NixOS option naming (
enable*).
- Enables tooling and linting to detect and document feature flags.
- No structural or evaluation changes needed.
Summary
This RFC proposes that most feature flags used as
callPackagearguments in nixpkgs should consistently start with eitherenableorwith.These feature flags are boolean inputs controlling optional functionality (e.g.
enableMPI,cudaSupport).They are not new attributes or structural changes to derivations — only a naming and semantic convention to make overrides, readability, and tooling more consistent.
At the same time, we propose to migrate the legacy
xxxSupportstyle (e.g.mpiSupport,cudaSupport) toward this unified form over time.Motivation
Feature flags in nixpkgs have evolved organically, leading to a mix of naming patterns:
mpiSupportpythonSupportenableMPIuseCudawithTestsThis inconsistency causes real issues:
mpiSupportorenableMPI.See #415208, where different packages use
xxxSupportorenableXxxinterchangeably for the same purpose.Proposal
1. Unified naming rule
A feature flag — a boolean argument controlling optional build functionality — must start with one of the following prefixes:
enableXxx— turns on or off an optional feature or backend.withXxx— includes or excludes auxiliary or additive components (tests, examples, docs).All other forms (
xxxSupport,useXxx,enableXxxSupport, etc.) are considered legacy.2. Examples
mpiSupportenableMPIpythonSupportenablePythonuseCudaenableCudaenableCudaSupportenableCudawithDocswithExamples3. Guidelines
enableXxx→ optional dependency or core feature toggle.withXxx→ optional additive component (tests, docs, examples).enableFooSupport.python = null) as feature flags.4. Scope
callPackage, not to attributes inside derivations.mkDerivationor the build system are required.Short Comparison:
enableXxxvsxxxSupportenableXxxxxxSupportservices.foo.enable.enable*).Summary:
enableXxxis clearer, machine-friendly, and consistent with the broader Nix ecosystem.xxxSupportdominates historically but is ambiguous and harder to reason about.enableXxx, while existing code can gradually migrate.Migration Strategy
Document the convention in the nixpkgs style guide and contributor documentation.
enableXxx/withXxx.xxxSupportas a legacy pattern.Perform a treewide replacement using codemods or scripted renames:
xxxSupport→enableXxxwhen it clearly represents a boolean flag.Benefits
enable*).