-
Notifications
You must be signed in to change notification settings - Fork 1k
Dep status -f doc and string display #1549
Dep status -f doc and string display #1549
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me.
Let's add tests for the changes in templateOutput.BasicLine
checking the rendered output.
Also, let's move the example with conditional template under -examples
output, similar to dep ensure -examples
, and have a simple template example in status help.
cmd/dep/status.go
Outdated
@@ -40,6 +40,15 @@ print an extended status output for each dependency of the project. | |||
TODO Another column description | |||
FOOBAR Another column description | |||
|
|||
You may use the -f flag to create a custom format for the output of the | |||
dep status command. The available flags you can utilize are as follows: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
flags
-> fields
Sounds good. I'll get those changes in. |
I turned out that there were some things I missed in the initial commit:
I also included the -example flag with some basic examples. I can change the examples/display for that if there's something off. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests look good with a slight enhancement mentioned inline.
I would wait for another review for the content of help and -examples. Maybe we can shorten it.
Moving from html/template
to text/template
is fine. I never realized that we were using html and not text. Maybe the IDE decided to insert html version and it didn't get much attention.
cmd/dep/status_test.go
Outdated
@@ -150,6 +157,19 @@ func TestBasicLine(t *testing.T) { | |||
t.Errorf("Did not find expected Table status: \n\t(GOT) %v \n\t(WNT) %v", buf.String(), wantStatus) | |||
} | |||
} | |||
|
|||
buf.Reset() | |||
template, _ := template.New("status").Parse("->{{.Revision}}~{{.Constraint}}~{{.Version}}<-") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's have all the available template fields here so that the test fails if anything stops rendering.
Sounds good. I'll get that fix in. I'll also take the example feature out, create it's own issue and pull request for review. |
@zkry let the example be there for now and wait for another review. Also, since we try to keep dep similar to go, we might do something similar to what |
Ok, I see now. That would be good to check. |
cmd/dep/status.go
Outdated
Display the list of package names constrained on the master branch. | ||
The -f flag allows you to use Go templates along with it's various | ||
constructs for formating the output data. See -help for available | ||
variables for this flag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small UX concern: I'd re-list the available variables here instead of making the user run a separate command. For most people trying to use this feature, I expect they'd want to see the example and the options side-by-side.
To keep it nice and DRY, a simple const templateVariablesLine = "ProjectRoot, Constraint, Version, Revision, Latest, and PackageCount.\n"
could be used in both places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess if we can put in a line of description telling the user where to go to see the variable names, we can instead add a line telling what those actually are. 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Full disclosure: I'm not a dep maintainer, but CONTRIBUTING.md isn't clear on if reviewers from the community are appreciated. Since I had already read the patch and @darkowlzz asked for more review, I figured I'd try to help.
cmd/dep/status_test.go
Outdated
@@ -150,6 +157,19 @@ func TestBasicLine(t *testing.T) { | |||
t.Errorf("Did not find expected Table status: \n\t(GOT) %v \n\t(WNT) %v", buf.String(), wantStatus) | |||
} | |||
} | |||
|
|||
buf.Reset() | |||
template, _ := template.New("status").Parse("PR:{{.ProjectRoot}}, Const:{{.Constraint}}, Ver:{{.Version}}, Rev:{{.Revision}}, Lat:{{.Latest}}, PkgCt:{{.PackageCount}}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, Moving this template string closer to expected output (like right above the tests
table definition) would help readability.
cmd/dep/status.go
Outdated
data := struct { | ||
ProjectRoot, Constraint, Version, Revision, Latest string | ||
PackageCount int | ||
}{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason not to reuse rawStatus here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought of that too actually. It probably would make more sense to use it instead of creating an anonymous struct.
if ok := strings.Contains(buf.String(), wantStatus); !ok { | ||
t.Errorf("Did not find expected template status: \n\t(GOT) %v \n\t(WNT) %v", buf.String(), wantStatus) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is good, but it doesn't actually ensure that these types remain of type string, or more importantly that templates using the eq
function continue to work which is sorta what this whole patch is about.
I'd recommend having another test (or another chunk in this test) that attempts equality on every field. This may not even need an expected output, but it should at least ensure that the template can be executed without errors.
Thanks for pointing that out. I forgot about that. |
1b53890
to
c4b6589
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just fix the merge conflict with 57f0a59 and this LGTM
👍 Ok, its fixed. It should be good now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems fine, just needs rebase
c4b6589
to
a3d5085
Compare
@sdboyer all good now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks a lot for working on this.
Update Changelog for #1549 and typo fixes
What does this do / why do we need it?
This pul requests chages the structure of the data fed into the template used by the
go status -f
command. The BasicStatus struct had fields that were not directly of type string making certain template constructs confusing (ex.dep status -f='{{if eq .Constraint "master"}}{{.ProjectRoot}}{{end}}'
doesn't work because .Constraint is of type gps.Constraint, not a string).This PR takes such elements and puts them into a structure whos type is string making the above example work.
In addition, I added some documentation to the help prompt explainging the usable field names and giving an example.
What should your reviewer look out for in this PR?
Is there any other place / a better place that I should document the -f flag?
Which issue(s) does this PR fix?
fixes #1497
fixes #1540