Status template output #1389
Status template output #1389
Conversation
| func (out *templateOutput) MissingFooter() {} | ||
|
|
||
| func (out *templateOutput) MissingLine(ms *MissingStatus) { | ||
| out.tmpl.Execute(out.w, ms) |
There was a problem hiding this comment.
Using the same template for BasicLine and MissingLine makes hard to write a template that handles both.
I think that -f should only provide formatting for BasicLine.
There was a problem hiding this comment.
@dolmen thanks for reviewing :)
I don't think there is any use-case for MissingStatus with templateOutput because MissingStatus is used only while printing the error invoked by input-digest mismatch due to missing packages. This function exists because it's required to implement the outputter interface and avoid empty output when user tries to use templateout and there's a inputs-digest mismatch due to missing packages.
A non-templateOutput status with missing packages error looks like this.
$ dep status
Lock inputs-digest mismatch due to the following packages missing from the lock:
PROJECT MISSING PACKAGES
github.com/pkg/errors [github.com/pkg/errors]
This happens when a new import is added. Run `dep ensure` to install the missing packages.
input-digest mismatch
When the user does $ dep status -f="some-template" only the table output in the above error message would be replaced by the template rendered content. I'm not sure if that can be useful rendered content in any way.
Is there some use-case that I'm overlooking? 🤔
cmd/dep/status.go
Outdated
| if cmd.template != "" { | ||
| templateOut = true | ||
| } | ||
|
|
There was a problem hiding this comment.
This block is not necessary. See below.
cmd/dep/status.go
Outdated
| @@ -231,6 +256,15 @@ func (cmd *statusCommand) Run(ctx *dep.Ctx, args []string) error { | |||
| o: cmd.output, | |||
| w: &buf, | |||
| } | |||
| case templateOut: | |||
| func (out *templateOutput) BasicFooter() {} | ||
|
|
||
| func (out *templateOutput) BasicLine(bs *BasicStatus) { | ||
| out.tmpl.Execute(out.w, bs) |
There was a problem hiding this comment.
Should errors be captured? Don't necessarily need to halt on error since it may not affect all lines (although go list -f does halt), but I'm not sure whether the feedback would be better in-line to out.w or routed to ctx.Out/Err. Maybe Err, to cleanly separate it for anything parsing.
There was a problem hiding this comment.
oh! I didn't realize that it returned an error. Maybe because we are not handling the returned error in any of the other writes, like error from fmt.Fprintf() in tableOutput and json.Encode() in jsonOutput. Encoding failure seems important to handle to me.
Routing the error to Err should be better; similar to how we keep the partial status output separate from the raised errors.
There was a problem hiding this comment.
@darkowlzz so is there a change to be made here? this was on my list to "merge fast, fail fast," but it seems like you're planning on a followup.
|
going to defer the error handling to a follow-up |
What does this do / why do we need it?
This implements
-fflag instatus, enabling template formatted output results.Example usage:
What should your reviewer look out for in this PR?
The implementation.
Do you need help or clarification on anything?
No.
Which issue(s) does this PR fix?
fixes #1374