Unfortunately, we don't have a good enough way to discern this
possibility. Technically we could add yet another attribute, but
that does not seem to be worth the cost at this point, in terms
of complexity and possibly even performance.
I take the blame for this one. I identified the need for the second
merge commit in review but didn't require it in the first merge.
These changes really should have been done in a single merge.
That would have prevented this situation.
This allows individual types to add attributes that would be discarded during normal evaluation.
Some examples:
types.submodule performs a submodule evluation which yields an 'evalModules' result.
It returns '.config' but makes the original result accessible via 'valueMeta' allowing introspection of '.options' and all other kinds of module evaluation results
types.attrsOf returns an attribute set of the nestedType.
It makes each valueMeta available under the corresponding attribute name.
hsjobeki: Using config in imports is possible in general. But its not possible to do conditional imports where the condition depends on config. Thats two different statements.
Co-authored-by: Johannes Kirschbauer <hsjobeki+github@gmail.com>
The `importApply` docs reference using the `_key` attr along with
`importApply` or `_file`, however the actual attr name used by the
module system is `key`.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Passing the elaborated system defeats what pkgs/top-level/default.nix
tries to do: Pass only the original args and let defaults be inferred.
The underlying problem is that lib.systems.elaborate can not deal with
arbitrary overrides, but will often return an inconsistent system
description when partially overriding some values. This becomes most
prominent if trying to override an already elaborated system.
* lib.modules.importApply: init
Brings variables from rich scopes to modules defined in separate files.
A helper for functions in files that return a module.
* lib.modules.importApply: Edit doc
Generally improve the quality. Notes:
- Not rendered to the manual yet, so probably the syntax could be
improved, but I have no way to test this now.
- The docs use `arg` vs `staticArg` in the code. This is intentional,
because the doc is pretty clear about the role of `arg` whereas
the code exists in a context where ambiguities are more harmful.
* Format
Benefits:
- some lookups happened in the hot path, and will now be slightly faster,
with only a variable lookup and no attribute selection
- it's now harder to accidentally use args.lib aka specialArgs.lib, which
has happened
- shorter
