New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Context introspection #2628
Context introspection #2628
Conversation
Previously, plain derivation paths in the string context (e.g. those that arose from builtins.storePath on a drv file, not those that arose from accessing .drvPath of a derivation) were treated somewhat like derivaiton paths derived from .drvPath, except their dependencies weren't recursively added to the input set. With this change, such plain derivation paths are simply treated as paths and added to the source inputs set accordingly, simplifying context handling code and removing the inconsistency. If drvPath-like behavior is desired, the .drv file can be imported and then .drvPath can be accessed. This is a backwards-incompatibility, but storePath is never used on drv files within nixpkgs and almost never used elsewhere.
On top of #2626 for convenience, can rebase if desired. |
BTW could you put these in a separate file (e.g. |
This can be very helpful when debugging, as well as enabling complex black magic like surgically removing a single dependency from a string's context.
e4acec6
to
948c879
Compare
I guess without one of the context discarding functions they're not, though I do think there's value in most of the time considering string context opaque and quasi-unobservable. Changed the names anyway.
Done |
@edolstra Any concerns? |
Yes it would be really nice to merge this soon. We use this for some testing. |
Running
|
Ah I guess this is because isValidPath doesn't know about paths "added" during the current eval in read-only mode? Is there an alternative? |
A partner of builtins.getContext, useful for the same reasons.
948c879
to
b30be6b
Compare
@edolstra Fixed, followed the logic in builtins.storePath |
Ping? |
outputs: If a non-empty list, the relevant path is a derivation | ||
and the provided outputs are referenced in the context | ||
(i.e. the kind of context you get when referencing | ||
.outPath of some derivation). Empty list if missing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have trouble interpreting "False / empty list if missing". This paragraph should presumably read "If the path is a derivation, then this attribute is a list ... Otherwise this attribute is omitted."
However, I wonder if it might be easier for the caller to always include this attributes with values false
and []
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it makes sense with respect to appendContext
to not include them.
Add primops to inspect and set context arbitrarily from the Nix language.