Open anacrolix opened 6 years ago
-v
means for me that I want/need the noise, most/all of it because I want to investigate/understand things/failures etc.
How many times have you found it useful for meta tags?
Drive-by suggestion: have multiple levels of -v
. -v
for "some noise" up to -vvv
for "tons of chatter."
Not to start a flame war, but, after switching the majority of my development to Go, the only thing I miss about NPM is being able to know what get
is actually doing. I don't know if it's a limitation of the network library, or a religious decision to keep things quiet unless there is an error- no news is good news. But for new Go users especially, it can appear there is something wrong when there are no blinkinlights during large package adds.
I work from many offices, on planes and in coffee shops and knowing quickly if there's a problem adding packages is important for productivity. If the first download is going to be slow then the rest are too, and I need to get up and go find a better connection or I'll waste time. go get
needs a typical, clear interactive mode that informs terminal users about what it's doing: package(s) it's fetching, rate (estimated completion if calculable), compiling, etc.
There have been many thread comments on this, and I'm not complaining, or piling-on. I'm really happy with Go- it's amazing. And that's why it deserves a first class package-add experience too.
OK, my piece said, back to code..
This is absolutely still a problem but we didn't get to it for Go 1.11. -v is a build flag that means "print the names of the packages being compiled". The fact that it got co-opted into "print a ridiculous amount of output about go get" needs to be undone.
Thank you for the confirmation. I expect with go mod this is a non-issue, I've not noticed any excessive logging since beginning to switch over.
See also #26152.
It's worth pointing out that niggling over the definition of -v
doesn't help. What one person may think is verbose, others may not. It's not specified that -v
should provide debug info regarding meta tags, so just make another flag for that.
being able to know what
get
is actually doing
I believe that is #15959.
This is interjected for every repo that uses meta tags. It would be useful if there were a failure only. Instead it disrupts the usual pattern of listing packages that have been consulted to fulfil the command. There are other ways to get this information a user can use if they were curious, or needed to debug the situation.
Here's a full sample of the noise in a typical circumstance: