Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/vgo: don't write column header line by default #24347

Closed
RalphCorderoy opened this issue Mar 11, 2018 · 11 comments

Comments

@RalphCorderoy
Copy link

commented Mar 11, 2018

Reading https://research.swtch.com/vgo-tour I see

$ vgo list -m
MODULE                VERSION
github.com/you/hello  -
golang.org/x/text     v0.0.0-20170915032832-14c0d48ead0c
rsc.io/quote          v1.5.2
rsc.io/sampler        v1.3.0
$ 

Those column headers are annoying when wanting to further process the output, requiring a tedious sed 1d or similar. Please consider dropping the columns headings; I think they're obvious in the cases I've seen. If you think new vgo users need them, then would an explicit add headers option do instead? That way, they can soon stop typing it after a day or two.

For comparison, goversion -mh doesn't output headers.

@gopherbot gopherbot added this to the vgo milestone Mar 11, 2018

@mvdan mvdan changed the title x/vgo: Don't header columns by default x/vgo: don't write column header line by default Mar 11, 2018

@dpinela

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2018

Wouldn't an option to disable the headings would do just as well in that case? If the output is primarily meant to be read by humans, then I think leaving them on by default is better.

@davecb

This comment has been minimized.

Copy link

commented Mar 11, 2018

Alas, script output often becomes considered a stable API.

If the output will ever change, you probably want a way to output a settable format, such as, for example, vgo list -m -o module,version

@myitcv

This comment has been minimized.

Copy link
Member

commented Mar 11, 2018

Or perhaps the -json flag could give more structured output here?

@dpinela

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2018

@davecb That's right. You don't need a new flag for that, though; there's already the -f option for exactly that purpose.

Then again, isn't the go tool explicitly not covered by the compatibility promise? So even with the option, any new release of Go could change the output or the flags anyway.

@RalphCorderoy

This comment has been minimized.

Copy link
Author

commented Mar 11, 2018

Hi @dpinela, No, an option to disable the header isn't as good because it gets in the way as much as having to delete the first line of output; the command becomes not vgo list -m but vgo list -m -h and muscle memory would suffer that tedium.

The columns are simple and their content readily identifies their meaning. It's not as if it's a description and half a dozen integers to a row, causing confusion as to what int means what. Novice vgo users can recognise a package name v. a semantic version, etc., so I doubt even they need a heading option. If it were there I think they'd stop using it within a day.

@myitcv, There's a whole world of Unix text processing that gets by just fine without JSON and I'm interested in vgo's output being smooth to use with that by default.

@myitcv

This comment has been minimized.

Copy link
Member

commented Mar 11, 2018

@RalphCorderoy I mention -json simply because go list already has this ability.

@slrz

This comment has been minimized.

Copy link

commented Mar 13, 2018

Removing the headers would also be consistent with the other go tools (test, list, …) which have none.

@as

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2018

If it's an error to output the headers, output the headers to standard error

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2018

I put the headers in to make the output clearer for the examples. I'm on the fence about whether they should stay. Probably not, but I won't remove them yet. That said, my expectation is that scripts would pull out what they need using the extra module-aware pieces of go list -f. It's just that those aren't implemented yet.

@rsc rsc added the NeedsDecision label Mar 27, 2018

@RalphCorderoy

This comment has been minimized.

Copy link
Author

commented Mar 28, 2018

I see that there might be a more official way for a script, but I'm more interested in the common ad hoc method of running vgo list -m and then deciding to run it again into a pipeline. Having to change the command at that point seems odd. Delaying the removal whilst folks are digesting the blog posts, etc., is fine.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 21, 2018

Change https://golang.org/cl/120198 mentions this issue: cmd/go/internal/list: add module support

@golang golang locked and limited conversation to collaborators Jun 27, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants
You can’t perform that action at this time.