Make imports from unrealised derivations work well with queries #22
Conversation
…ilures due to read-only mode
…sing bogus string values
…e cannot be evaluated in read-only mode
…valuated due to read-only error at the end
… can't be considered prebuilt
…ilable due to read-only mode I'm not sure if the exclamation point is valid in the xmlOutput case, this may change in a later commit
…t be evaluated in readonly mode
…hose name cannot be evaluated in readonly mode should keep the VersionDiff unchanged
…annot be evaluated in readonly mode
… cannot be evaluated in readonly mode
… cannot be evaluated in readonly mode
|
Ok @edolstra , I think this is ready for review. nix-env -q should now be more versatile in the import from unrealised derivation case. Future work includes adding a flag to allow nix-env -q to realise such derivations, and possibly some sort of max-depth feature for queries (though I think that issue will be better addressed when we have a real broken case in front of us). |
|
@edolstra ping? |
| columns.push_back(i->name); | ||
| else | ||
| if (xmlOutput) | ||
| attrs["name"] = "!name-unknown-in-readonly-mode!"; |
There was a problem hiding this comment.
Isn't it better to just omit unknown attributes rather than emit a value like "!name-unknown-..."? Especially in the XML output case, omitting an attribute shouldn't cause any problems. In the text output case, it might cause problems if the output is processed by a script like "awk { print $3 }". But in that case I would prefer a shorter string like "?".
There was a problem hiding this comment.
Alright, I'll just omit the fields in every case unless you know of a specific case where the field needs to be output.
|
Whatever happens with #31, this definitely isn't the way we want to go. |
Print syntactially invalid attribute names as strings.
Don't include store dir in IPFS JSON keys
I'm opening this pull request now to have a place for a dialog as I work on this. I'll let you know when it's done and ready to pull.