This reverts commit ce8f304bb6.
The problem was simply a typo (nestedTypes.elemType ->
type.nestedTypes.elemType) ! And CI didn't run for lib in the orginal
PR which is why it didn't get caught.
This gives people some flexibility when they need a path type, and
prevents a "combinatorial explosion" of various path stops.
I've re-implemented our existing `path` and `pathInStore` types using
`pathWith`. Our existing `package` type is potentially a candidate for
similar treatment, but it's a little quirkier (there's some stuff with
`builtins.hasContext` and `toDerivation` that I don't completely
understand), and I didn't want to muddy this PR with that.
As a happy side effect of this work, we get a new feature: the ability
to create a type for paths *not* in the store. This is useful for when a
module needs a path to a file, and wants to protect people from
accidentally leaking that file into the nix store.
Probably a missed left over from somewhere in
the commit 58f385f680.
As can be seen in that commit where this line was introduced,
"$@" was also just emptied by the last `set` call in line 169.
This line is currently valid, but breaks suddenly when somewhere earlier
a `set --` instruction is used in the future.
Neither in commit 58f385f680
nor in PR https://github.com/NixOS/nixpkgs/pull/197547
have I found anything stating that this "defect" was intentional.
Previously, for values of type list, the merge function would only retain the value
if the number of option definitions was less than or equal to 1, and would throw an
error for conflicting definitions to avoid potentially unwanted list merges.
This change removes that logic, defaulting to the 'mergeEqualOption' function for
values of type list. This approach maintains the same safeguard against merging
different lists while allowing lists with identical values to be merged.
* 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
And fix locations to not break the test.
This is a rare case where another change is required after formatting.
We do this in a separate commit so that we don't need to do it in the
treewide reformatting PR.
- Clear separation between failures
- Move error regex close to error message, which is at the bottom
of a fairly long trace
- Move most relevant and consistent info to bottom of terminal:
the location of the failure.
Some editors including vscode heuristically resolve file paths
on Ctrl+click.
- Less wordy - easy to glance
- Capitalized prefixes to distinguish from Nix's own logging
The practical use for this should be very limited because I don't
think anyone should change `lib`, let alone change `lib.functionArgs`,
but, but it would be even stranger to rely on `args.lib` (or really
`specialArgs.lib` for what's clearly a behavior of the current
`evalModules`, which uses its own ambient lib for basically everything.
The shadowing of `lib` by `args.lib` here seems to be a small mistake,
which is easy to make.
This doesn't change uniq. Why not?
- In NixOS it seems that uniq is only used with
simple types that are fully checked by t.check.
- It exists for much longer and is used more widely.
- I believe we should deprecate it, because unique was
already better.
- unique can be a proving ground.
Currently, the `lib/tests/modules.sh` test checks the output of
`nix-instantiate --eval` without `--json`, which outputs an unspecified
human-readable format.
This patch modifies `modules.sh` to use the `--json` output instead, to
be robust against future changes to `nix-instantiate` output.
