Conversation
| > This option produces ambiguous output which is not suitable for machine | ||
| > consumption. For example, these two Nix expressions print the same result | ||
| > despite having different types: | ||
| > This option produces output which can be parsed as a Nix expression which |
There was a problem hiding this comment.
| > This option produces output which can be parsed as a Nix expression which | |
| > This option may produce output which can be understood as a Nix expression which |
There was a problem hiding this comment.
The issue is that the output includes valid Nix syntax that does not parse as the value it's standing in for. It's specifically about the parsing. Humans will be able to look at <CODE> and understand it's a placeholder through context clues, machines will not.
There was a problem hiding this comment.
But it would be wrong to assume that you can obtain the value from the output somehow if you are not using --strict.
There was a problem hiding this comment.
Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.
The motivation for my suggestion is as follows:
- Parsing by a human is better described as understanding.
- may is only there because the output may also be unambiguous - such as when passing
--strict.
I did make a mistake though. (also "to be" is a bit simpler)
| > This option produces output which can be parsed as a Nix expression which | |
| > This option may produce output which can be misunderstood to be a Nix expression which |
Apart from this suggestion, it'd be helpful to mention --strict as a possible solution.
There was a problem hiding this comment.
Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.
This fails to consider machines that are bad :)
Imagine for a minute that someone calls nix-instantiate, likes the output, then immediately integrates it without thinking whatsoever.
This is a reason we need to make this obviously not for machine consumption. Perhaps we should print a warning to stderr if stdout is a pipe.
There was a problem hiding this comment.
--strict still includes «repeated» and «potential infinite recursion».
Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.
This is a currently undocumented assumption.
There was a problem hiding this comment.
Because it doesn't output (general) expressions, no machine will be programmed to parse it as expressions.
This is a currently undocumented assumption.
It is a personal assumption of mine, and I don't think it's relevant enough to document.
Nonetheless, if you think the warning or any other docs are still insufficient, feel free to open another PR. (And/or discuss here, etc)
9999years
force-pushed
the
printer-followup
branch
from
436e6f0 to
f73e501
Compare
roberth
left a comment
roberth
left a comment
There was a problem hiding this comment.
It's a good change, and while could discuss more, that'd be at the cost of higher impact changes we wouldn't be making.
Thank you for following up!
Printer followup (cherry picked from commit 51f524c) Change-Id: I29214cc86c5e846cbcfec382022293a70011b316
4 participants
Follow-up PR to address post-merge comments in #9606.