Previously it would fail with
error: attribute 'nonexistent' missing
at nixpkgs/lib/filesystem.nix:29:10:
28| if dirOf path == path then "directory"
29| else (readDir (dirOf path)).${baseNameOf path};
| ^
30|
Previously this function couldn't handle / being passed, it would throw
an error:
error: attribute '' missing
at nixpkgs/lib/filesystem.nix:24:20:
23| */
24| pathType = path: (readDir (dirOf path)).${baseNameOf path};
| ^
25|
Consequently this also fixes the
lib.filesystem.{pathIsDirectory,pathIsRegularFile} functions.
This is to avoid stealing keys from submodules. `class` might be
common enough that reinterpreting existing `class` attributes in
configurations as a declaration leads to fairly widespread problems.
This is appears to be a fairly common mistake for beginners who want
to build larger things from the system configurations, such as NixOps
networks, etc. Further explanation seems appropriate.
This makes the following work
disabledModules = [ foo.nixosModules.bar ];
even if `bar` is not a path, but rather a module such as
{ key = "/path/to/foo#nixosModules.bar"; config = ...; }
By supporting this, the user will often be able to use the same syntax
for both importing and disabling a module. This is becoming more relevant
because flakes promote the use of attributes to reference modules. Not
all of these modules in flake attributes will be identifiable, but with
the help of a framework such as flake-parts, these attributes can be
guaranteed to be identifiable (by outPath + attribute path).
This makes bisecting nix a bit easier.
Example reproducer, invoked from nix directory:
```bash
nix-build ../nixpkgs/lib/tests/release.nix --arg nix '(builtins.getFlake "git+file://${toString ./.}").packages.x86_64-linux.default'
```
Render un`_type`d defaults and examples as `literalExpression`s using
`lib.generators.toPretty` so that consumers don't have to reinvent Nix
pretty-printing. `renderOptionValue` is kept internal for now intentionally.
Make `toPretty` print floats as valid Nix values (without a tilde).
Get rid of the now-obsolete `substSpecial` function.
Move towards disallowing evaluation of packages in the manual by
raising a warning on `pkgs.foo.{outPath,drvPath}`; later, this should
throw an error. Instead, module authors should use `literalExpression`
and `mkPackageOption`.