What it does: line and column level *declaration* position information:
$ nix repl .
nix-repl> :p nixosConfigurations.micro.options.environment.systemPackages.declarationPositions
[ { column = 7; file = "/nix/store/24aj3k7fgqv3ly7qkbf98qvphasrw9nb-source/nixos/modules/config/system-path.nix"; line = 63; } ]
Use cases:
- ctags over NixOS options, as will be presented at NixCon 2023 ;)
- improving the documentation pages to go to the exact line of the
declarations.
Related work:
- https://github.com/NixOS/nixpkgs/pull/65024
This one does it for all *definitions* rather than declarations, and
it was not followed through with due to performance worries.
- https://github.com/NixOS/nixpkgs/pull/208173
The basis for this change. This change is just a rebase of that one.
I split it out to add the capability before adding users of it, in
order to simplify review. However, the ctags script in there is a
sample user of this feature.
Benchmarks: conducted by evaluating my own reasonably complex NixOS
configuration with the command:
`hyperfine -S none -w 1 -- "nix eval .#nixosConfigurations.snowflake.config.system.build.toplevel.outPath"`
```
Benchmark 1: nix eval .#nixosConfigurations.snowflake.config.system.build.toplevel.outPath
Time (mean ± σ): 8.971 s ± 0.254 s [User: 5.872 s, System: 1.388 s]
Range (min … max): 8.574 s … 9.327 s 10 runs
Benchmark 1: nix eval .#nixosConfigurations.snowflake.config.system.build.toplevel.outPath
Time (mean ± σ): 8.766 s ± 0.160 s [User: 5.873 s, System: 1.346 s]
Range (min … max): 8.496 s … 9.033 s 10 runs
```
Summary of results: it seems to be in the noise, this does not cause any
visible regression in times.
Added basic generators.toGitINI test.
Mostly taken from 958c06303f/tests/modules/programs/git/git.nix.
The ${"\t} escape is used so that the lines aren't recognized as "Wrong
indent style".
mkOption does not require a `type` argument and does not set the
resulting attribute if it is not given. Consequently, we need to be
prepared to merge options that have no type information.
Having the current bash hash present in the nixpkgs tree makes Nix
detect bash as a runtime dependency of nixpkgs, which in turns messes up
`fetchFromGitHub` due to https://github.com/NixOS/nix/issues/6660
toLosslessStringMaybe is not used by anything other than lib/tests,
so it can be private to that file.
I don't think this function was terribly well thought-through. If
people start using it, we will become permanently dependent on the
ability to test platforms for equality. It also makes the
elaboration process more fragile, because it encourages code outside
of nixpkgs to become sensitive to the minute details of how
elaboration happens.
This will let us make assertions involving _module.args.pkgs, which
is not an option but a value attribute, and therefore doesn't have
its own highestPrio to inspect. The new function gives us that info.
We already have examples for these, but since we didn't actually
recognise the doubles, it wasn't possible to build any packages for
them without setting allowUnsupportedSystem.
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`.
With the goal of making `toPretty` suitable for rendering option
values, render derivations as `<derivation foo-1.0>` instead of
`<derivation /nix/store/…-foo-1.0.drv>`.
This is to avoid causing sudden evaluation errors for out-of-tree
projects that have options with `default = pkgs.someUnfreePackage;` and
no `defaultText`.
Add trace items that provide context for a failed definition that
can not be caught within the Nix language.
This also adds a test for the `tryEval` behavior of `showDefs`.
A tricky thing about FreeBSD is that there is no stable ABI across
versions. That means that putting in the version as part of the config
string is paramount.
We have a parsed represenation that separates name versus version to
accomplish this. We include FreeBSD versions 12 and 13 to demonstrate
how it works.
