Import from derivation: Better queries, better errors #31
Conversation
|
cc @edolstra |
|
Oh, "the other PR" is #22 for those who haven't been following this work. |
|
@edolstra ping |
|
Any chance of this making it into 1.1? |
|
@edolstra ping :) |
|
@edolstra I've rebased onto latest master. I'll be doing more work on top of this branch, so future pull requests may assume this was merged. |
…to get one meta attribute
…t to get the description
…yError when forceValue'd
…ors must be assumed not to be prebuilt
…h, and meta attributes
None of the cases that turned handling off didn't have readOnly set anyway.
…tion in read-only mode, we shouldn't throw an exception just because we're trying to check for substitutable paths
|
Rebased, and I'll keep that up if more changes are pushed to master. |
| @@ -6,6 +6,29 @@ | |||
| namespace nix { | |||
|
|
|||
|
|
|||
| string DrvInfo::queryName(EvalState & state) const | |||
There was a problem hiding this comment.
What's the reason for queryName() and querySystem()?
There was a problem hiding this comment.
So getDerivation() doesn't need to evaluate any of the derivations attributes, and to allow graceful handling of the case where name or system depend on an import from derivation in the future
|
Giving up on this getting merged |
|
@edolstra can we reopen this? |
|
@shlevy thanks for doing this! Could you describe what this is doing to make it easier for someone to pick up and revive it? For example, how would I test that it's behaving as expected? |
We're not going to use it. Fixes: NixOS#31 Change-Id: Ib17a2eb6cae1ecbbf9ad1062e576ba6107a3c13b
This is a new attempt at getting queries to work well with imports from derivations, taking the approach I suggested in the comments on the other PR. Note that currently the case where 'name' or 'system' require importing from an unrealized derivation (A silly case IMO) is not handled, though that can be easily added.