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.

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

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

@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.

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.

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

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

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

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.

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.

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