cmd/go: go get can block for extremely long periods of time without any indication of functionality

[fake-name]

I haven't used go before, and I'm trying to get a tool I found on github working. I just spent the last ~30 minutes assuming go get was broken, because it just sat there doing nothing for 10+ minutes.

I ran it as go get ./..., and I assumed I had done something like cat with no arguments, and it was waiting for data over stdin or something.

go get needs to output something to indicate it's actually doing anything.

---

I've read over #18388 #22356 #22800 and am completely unconvinced.

The consensus on those answers is:

Most go tools are quiet by default,

Uh, [citation needed]. This is completely not true.

At the moment, I can't think of a single CLI tool I use that can block for long periods of time that doesn't have some output. apt-get has some status output. git has some status output. cmake has some status output. wget has some status output.

Frankly, barring some poorly written tools of my own creation, I don't think I can recall ever seeing a tool that blocked for very long periods of time at start with absolutely no output.

I don't need a progress bar or whatnot, but as someone trying to use some go tooling for the first time, having go get print something like "fetching dependencies. this may take a while` before blocking would have been enough.

---

Additionally, the -v flag *is not documented. I looked at go get --help, and it's not mentioned at all (I thought about it, but assumed it wasn't supported, since the help page didn't mention it).

[fake-name]

This isn't a proposal. It's a bug with the current behaviour.

I can't think of any way the current way it works is correct.

[agnivade]

Additionally, the -v flag *is not documented. I looked at go get --help, and it's not mentioned at all

It is there in the flag description section. Although not in the usage section. That needs a fix.

The -v flag enables verbose progress and debug output.

Assuming that the -v flag is properly documented, does your use case suffice by using -v ?

The overall opinion is varied on this. Some people want their tools to be quiet and only print errors. While some think doing a -v by default is too much output. While I agree that go get ./... does take quite long to run sometimes and the experience can be very frustrating, I don't think a blanket msg saying "This might take some time" is an ideal solution.

[fake-name]

It is there in the flag description section. Although not in the usage section. That needs a fix.

I could have sworn I grepped the help and didn't find it, but there it is. Gah. I probably fail at grep.

The overall opinion is varied on this. Some people want their tools to be quiet and only print errors.

Name one package manager like this that has no output by default. I've used npm, pip, apt-get, apt, pacman, yum, choco, and probably others I can't remember, and they all have status output.

There are plenty of tools that have a --silent flag, or similar, but none I can think of that are silent by default.

I do think the -v output is probably a bit much for normal operation, but no output without any indication of function for 10+ minutes is completely ridiculous, unless such behavior is specifically asked for.

[gopherbot]

Change https://golang.org/cl/85797 mentions this issue: cmd/go: add -v option in the usage section for get

[moar55]

I posted one of the issues @fake-name referenced. I agree that little indication of progress should be shown even if not a progress bar. There can be a compromise between no indication whatsoever and too detailed (verbose) indications.

[cznic]

If one wants to see what's going on, -v and/or -x provides that. Making the default noisy spams the output for all others who don't want/need it.

[ALTree]

Most go tools are quiet by default,

Uh, [citation needed]. This is completely not true.

Please read carefully what I wrote.

Most go tools are quiet by default

I'm talking about go tools. Most go commands and tools by default print nothing on success. build builds packages and prints nothing, except when there's a compilation error; even if the compilation process takes half an hour. install does the same. vet prints nothing, unless it has a warning to emit. And so on.

When I write "most go tools are quiet by default" I'm thinking about internal consistency (i.e., making all go commands and tools behave in a similar way regarding when to write output).

It is also true that most tools always do their job quickly -unless you're e.g. building a huge codebase- while go get is routinely slow and it's usually the one that stumbles newcomers. I'm not sure it's worth breaking internal consistency by making get emit output by default, considering that you already have a way to make it verbose (-v, similar to other commands).

One thing we could do is make more clear that the command is silent by default, for example in go get --help, after the short description but before the flags list:

The command is quiet by default, and emits no output unless an error occurs. To make it verbose, ..

or something like that.

[fake-name]

I'm talking about go tools. Most go commands and tools by default print nothing on success.

Point taken.

In that case, the entire go ecosystem has broken assumptions, that makes it inconsistent with every other ecosystem I've ever touched.

Making the default noisy spams the output for all others who don't want/need it.

Who exactly doesn't want it?

Functionally, it's a package manager. It should be expected to operate like every other package manager, or if you're going to break with consistency, there should be a good reason. "Other go CLI tools are quiet" is not a good reason, particularly when you realize that the package manager is one of the first things people come into contact with when trying to use the language.

Note: I personally think a package manager acting like a package manager is much more important then it being consistent with other go tools. YMMV

All this started because I just wanted to execute a program written in go. The way it works now, "normal behaviour" is indistinguishable from the tool being broken, unless you blindly let it sit at the command prompt seemingly doing nothing for 10+ minutes (at least in some cases).

It doesn't even use enough CPU to indicate it's doing something (presumably because it's blocked on network stuff).

[cznic]

Who exactly doesn't want it?

Many unix-y programmers. It's how most unix tools work - for decades.

Functionally, it's a package manager. It should be expected to operate like every other package manager, or if you're going to break with consistency, there should be a good reason.

It's the opposite. Unix tools are consistently quiet until they have to say something.

"Other go CLI tools are quiet" is not a good reason, particularly when you realize that the package manager is one of the first things people come into contact with when trying to use the language.

It should be easy to make an alias for the go get command that adds -v and/or -x. Forcing the noisy output is your preference, no problem with that, but it's not automatically the "right thing" because of that.

All this started because I just wanted to execute a program written in go. The way it works now, "normal behaviour" is indistinguishable from the tool being broken, unless you blindly let it sit at the command prompt seemingly doing nothing for 10+ minutes (at least in some cases).

You're probably coming from Windows, I guess. I can tell you that I understand your pain very well. I have the same desperate feeling of nothing working as expected when I occasionally must use Windows. But forcing unix expectations to all Windows users would be a patently bad idea, do you agree?

[fake-name]

You're probably coming from Windows, I guess.

Nope. I do almost all my dev work on linux.

Unix tools are consistently quiet until they have to say something.

Name one package manager that's silent default.

Forcing the noisy output is your preference, no problem with that, but it's not automatically the "right thing" because of that.

Well, apt-get, yum, pip, npm, and (it's been a while) pacman are all not silent by default, so if you come into this from the perspective of having used any other package manager on linux, status output is the standard.

[cznic]

Nope. I do almost all my dev work on linux.

The Times They Are a-Changin'

Unix tools are consistently quiet until they have to say something.

Name one package manager that's silent default.

I'm talking about unix tools and I do not even consider go get to be a package manager. You insist on talking about package managers instead as if they're not unix tools. Yes, some modern unix tools do not keep the well established tradition of tool being quiet by default when their purpose is other than to produce output. Yes, I consider it bad practice. If I want to know what apt-get or git is doing, I prefer to ask for it, not by default ruining the visual context of what I've been doing in the terminal in the previous commands, because now they are either many lines away from the screen or lost completely when the scroll buffer is set to a fixed length.

But this all is in accordance with how all the good values of unix are being slowly ruined in general. systemd anyone?

[fake-name]

I'd even go more general then package manager, and say name one linux CLI tool that can block for > 1 second and has no CLI output. The only thing I can think of is cp on a very, very large directly.

And yes, I'm talking about package managers, because that's what go get is, and the expectations for it should be commensurate.

You mention git. It has status output too!. I think maybe you need to recognize that "linux CLI tools are silent by default" was never true. They generally should be simple, and do one thing well, but neither of those have anything to do with their output. If you don't want to see the output, just pipe it to /dev/null or something.

Frankly, I bought up package managers because I think they're a great example of a complex unix CLI tool. As far as I know, they started on *NIX, so the fact that they are not completely silent kind of directly contravenes the entire "silent-by-default is unixy" argument.

Heck, looking at dpkg from 1994, and yep, it has status output.

[cznic]

And yes, I'm talking about package managers, because that's what go get is, and the expectations for it should be commensurate.

Sounds like a ruling from an authority with decisive power about this question. There's nothing to add.

[ALTree]

go get is not a package manager, it doesn't have have the concept of 'version'. It's more correct to see it as a simple Go package downloader. dep (https://github.com/golang/dep) is a WIP package manager for Go that is similar to the other package managers you keep mentioning. 2018-01-05 11:58 GMT+01:00 Connor Wolf <notifications@github.com>:

…

I'd even go more general then package manager, and say name one linux CLI tool that can block for > 1 second and has no CLI output. The only thing I can think of is cp on a very, very large directly. And yes, I'm talking about package managers, *because that's what go get is*, and the expectations for it should be commensurate. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23332 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADa683iBl8w5qGxSuA1sImVnFsCaySxvks5tHgBngaJpZM4RSkpW> .

[fake-name]

go get is not a package manager, it doesn't have have the concept of
'version'. It's more correct to see it as a simple Go package downloader.

Well, point taken.

Can we say it should act like wget and output status, then?

[ALTree]

Can we say it should act like wget and output status, then?

Can you explain why it should? Because it confuses newcomers? It only happens *once*. Then you learn that it's quiet by default, and that's it. On the other hand, if you make it loud by default, you'll be printing useless information for everyone else, forever. I'm not sure it's worth it. I already suggested a less invasive way to make this easier for newcomers (an update to the --help text, which is surely the first thing you look at if you're puzzled by empty output). Would that have helped you? 2018-01-05 12:08 GMT+01:00 Connor Wolf <notifications@github.com>:

…

go get is not a package manager, it doesn't have have the concept of 'version'. It's more correct to see it as a simple Go package downloader. Well, point taken. Can we say it should act like wget and output status, then? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23332 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADa681xgy7MoWcK_WF9lJphN9F4_PTidks5tHgLEgaJpZM4RSkpW> .

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)