Skip to content
This repository has been archived by the owner on Jun 6, 2022. It is now read-only.

added template for output #83

Closed
wants to merge 5 commits into from

Conversation

jasinner
Copy link
Collaborator

@jasinner jasinner commented Oct 2, 2018

Fixes Issue #33

@jasinner jasinner mentioned this pull request Oct 2, 2018
Copy link
Collaborator

@twaugh twaugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Added some comments.

One idea for improving this would be to instead provide a function that parses the template, using the default value if the supplied template is empty. This would avoid having to parse the template multiple times, and the calls to Display() would be replaced by calls to t.Execute(), with a single call to the parsing function up front to get the template to use.

//Display a Reference using a template
func Display(writer io.Writer, customTemplate string, ref *Reference) error {
if customTemplate == "" {
tmpl, err := template.New("output").Parse(defaultTemplate)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case perhaps we could just customTemplate = defaultTemplate (the caller is not affected by this) and fall through to the case where a custom template has been supplied.

}
err = tmpl.Execute(writer, ref)
if err != nil {
return err
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once tmpl.Execute(writer, ref) is the last thing to do, If we aren't going to use anything like errors.Wrap() on the error we could just immediately return that result and leave the checking to the caller, e.g. return tmpl.Execute(writer, ref).

backvendor/display_test.go Show resolved Hide resolved
@@ -36,6 +36,7 @@ var importPath = flag.String("importpath", "", "top-level import path")
var depsFlag = flag.Bool("deps", true, "show vendored dependencies")
var excludeFrom = flag.String("exclude-from", "", "ignore directory entries matching globs in `exclusions`")
var debugFlag = flag.Bool("debug", false, "show debugging output")
var template = flag.String("template", "", "go template to use for output with Rev, Tag and Ver")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it's worth putting the default value here instead of having to work out whether to use a fallback in Display()? (But don't want to clutter the help output, so not sure...)

main.go Outdated
func display(template string, name string, ref *backvendor.Reference) {
var builder strings.Builder
builder.WriteString(name)
backvendor.Display(&builder, template, ref)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably want to check the error.


func (t TemplateError) Error(template template.Template) string {
return fmt.Sprintf("display: Error creating template from %v", template)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TemplateError isn't used.

backvendor/display.go Outdated Show resolved Hide resolved
)

func TestDisplayDefault(t *testing.T) {
const expected string = "@4309345093405934509 =v0.0.1 ~v0.0.0.20181785"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove string from this declaration (and the other similar ones) as the type is inferred from the value.

const expected string = "@4309345093405934509 =v0.0.1 ~v0.0.0.20181785"
ref := &Reference{Rev: "4309345093405934509", Tag: "v0.0.1", Ver: "v0.0.0.20181785"}
var builder strings.Builder
var tmpl, err = Display("")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would normally be written tmpl, err := Display("")

if err != nil {
t.Fatal(err)
}
tmpl.Execute(&builder, ref)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably check for errors from this call, and the other similar ones.


func TestDisplayNoTag(t *testing.T) {
const expected string = "@v0.0.0.20181785 ~4309345093405934509"
ref := &Reference{Rev: "v0.0.0.20181785", Ver: "4309345093405934509"}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Rev and Ver fields look like their values are swapped. Rev is a revision (commit ID), Ver is a semantic version or pseudo-version.

main.go Outdated
builder.WriteString(name)
var tmpl, err = backvendor.Display(template)
if err != nil {
log.Warningf("Error parsing supplied template, using default. %s ", err)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather just abort at this point (log.Fatalf) rather than falling back to the default template.

@twaugh
Copy link
Collaborator

twaugh commented Oct 4, 2018

The merge history of this branch is quite messy:

| *   a61eba7 -- Merge branch 'output-template' of github.com:jasinner/backvendor into output-template (35 hours ago)
| |\  
| | * 8628b57 -- added template for output (2 days ago)
| |/  
|/|   
| * eb48431 -- added template for output (35 hours ago)
|/  
* 1dd351b (tag: v0.0.4)

Could you please re-base it onto master so there is just a single commit with the changes? (I couldn't see how to do this myself without creating a new commit from "git diff master output-template"...)

In general it is quite usual with GitHub to have a feature branch whose existing commits you amend, and force-push the changes. Instead of merging the master branch into the feature branch, re-base the feature branch on top of the master branch. GitHub knows how to track all of that -- it just follows the branch name wherever it goes.

@jasinner jasinner mentioned this pull request Oct 5, 2018
@jasinner jasinner closed this Oct 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants