Rename to mkPerSystemType and mkPerSystemOption respectively, since
the flake-parts deferredModule implementation has different semantics
than Nixpkgs' types.deferredModuleWith (list merge vs single module).
The old names are kept as deprecated aliases. Add mkLegacyDeferredModuleType
as internal helper preserving the list-merge behavior.
flake-parts uses `evalModules` with the `class` argument, which was
added in Nixpkgs 23.05. Update minVersion to reflect the actual
minimum supported version.
The deferredModule type was pioneered in flake-parts for perSystem.
The Nixpkgs version (lib.types.deferredModuleWith) has an improved
merge function that returns a single module, whereas this version
returns a list.
The `lib.deferredModuleWith or (...)` pattern never matched because
`lib.deferredModuleWith` doesn't exist - only `lib.types.deferredModuleWith`.
This was always using flake-parts' own implementation.
The workaround is no longer needed since Nixpkgs 22.05
(https://github.com/NixOS/nixpkgs/pull/156533).
Declaring options directly in a submodule now works, e.g. `options.flake.foo`.
The function is kept for backwards compatibility but documented as deprecated.
The minimum supported Nixpkgs lib version is already 22.05, so this change
does not drop support for any previously supported version.
Adding "placeholder" parameter to the attrs type allows changing the name that shows up in the docs. Since we have two in a row, this adds clarity here.
The memoize function is not a pretty thing in terms of implementation,
but it's exactly what we need to solve this UX problem and performance
problem.
Without this, every distinct `withSystem` call will cause a re-evaluation
of the `perSystem` module, which is inefficient. Now, it's a one-time
13KB and length(system) attribute lookups: negligible compared to any
instantiations and such.
Nix doesn't offer memoization for functions yet, so this is the best we
can do.
Initially this had some feature checking with lib.functionArgs, but
I don't think this is useful. The _class attribute is not supported
by long-unsupported Nixpkgs (<23.05) anyway, so let's keep it simple.
The difference is that moduleLocation is "guaranteed" reliable data,
whereas errorLocation is the best choice for error messages in the core.
moduleLocation is suitable for the module key attribute.
errorLocation is best for the *ROOT* module _file attribute.
Initially I applied errorLocation in too many places. It is only needed
when the flake output attribute names are strict in it.
To avoid confusion, I'm not exposing errorLocation to the modules, until
we have a concrete use case for it.
`outPath + "/flake.nix"` is technically an unfounded assumption,
except almost all calls will be made from flake.nix.
It surely is a lot better than `<unknown location>`.
