Make rootFS's showPath() render the paths from the original accessors#12532
Make rootFS's showPath() render the paths from the original accessors#12532edolstra wants to merge 3 commits intoNixOS:masterfrom
Conversation
|
🎉 All dependencies have been resolved ! |
This makes paths in error messages behave similar to lazy-trees,
e.g. instead of store paths like
error: attribute 'foobar' missing
at /nix/store/ddzfiipzqlrh3gnprmqbadnsnrxsmc9i-source/machine/configuration.nix:209:7:
208|
209| pkgs.foobar
| ^
210| ];
you now get
error: attribute 'foobar' missing
at /home/eelco/Misc/eelco-configurations/machine/configuration.nix:209:7:
208|
209| pkgs.foobar
| ^
210| ];
82cb354 to
172d57e
Compare
|
It seems that this would affect the equality of roots. That seems acceptable for entirely flake-based code, but some Nixpkgs and third-party code will be used in this context without the code or their maintainers being aware of the change. let rootOf = lib.converge dirOf;
in rootOf self.outPath != /.;This seems to bring us close to the semantics of #11367, which also introduces distinct roots, but I dont think this PR implements something to avoid creating those |
| /** `"unknown"` */ | ||
| Value vStringUnknown; | ||
|
|
||
| using StorePathAccessors = std::map<CanonPath, ref<SourceAccessor>>; |
There was a problem hiding this comment.
I think it would be more future-compat if this did not use CanonPath keys, both for lazy trees and for Windows.
There was a problem hiding this comment.
Right now it must use CanonPath, because we don't have a concept of non-CanonPaths in the virtual filesystem exposed in the evaluator.
I don't think so. This PR should only affect the display of error messages. It shouldn't change the semantics of evaluation. |
|
Closing for #12915. |
Motivation
This makes paths in error messages behave similar to lazy-trees, e.g. instead of store paths like
you now get
This should also enable fixing #4507 (similar to lazy-trees) but that will require a bit more work.
Depends on #12512.
Context
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.