Closed bobwhitelock closed 6 years ago
Rebased on develop
@WilliamMcCumstie
However I don't think we should colourise the output in
metal eval
as it is meant to be machine readable. The colouriser will add a bunch of control characters that are essentially meaningless to a machine.Instead
metal view
should be colourised by default (maybe a flag to turn it off). Thenmetal eval
should always return regular text.
ATM for both commands we colour the output if they're outputting to a terminal, or if the --color-output
is passed - I think in both cases this is useful/reasonable behaviour as:
If the command is outputting to a terminal you are (almost certainly) using it interactively, so getting colourised JSON as output is helpful as it allows you to see at a glance the output of the command. This is still the case for metal eval
as it's useful to try things out in a terminal until you get the results you need, even if it's ultimately intended to be used by another program.
If the command is not outputting to a terminal (which will almost certainly be the case when using metal eval
programmatically), you probably don't want a load of terminal control characters mixed in with the useful output, so we should suppress the colourising by default.
There are still cases where it is useful to get coloured output when not outputting to a terminal, e.g. to allow paging the output like metal view nodes.first --color-output | less -R
, so we have the --color-output
to allow this behaviour.
Hold off on merging this for a second if you were planning to soon, may want to make another tweak :slightly_smiling_face:
@WilliamMcCumstie change made, merge at will again
This PR introduces a new
metal eval
command, with the current behaviour ofmetal view
, and revertsmetal view
to the behaviour it had prior to #430. This should fix #431 by giving us distinct commands for human (metal view
) vs programmatic (metal eval
) inspection of the Metalware namespace, which means each of these can be specialised for its purpose rather than conflicting as described in that issue.Based on #433.