Go: cmd/go: attempting to download a package/module that doesn't exist generates an unhelpful error message

[dylan-bourque]

What version of Go are you using (go version)?

$ go version
go version go1.12.1 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

GOARCH="amd64"

GOBIN=""

GOCACHE="/home/dylan.bourque/.cache/go-build"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOOS="linux"

GOPATH="/home/dylan.bourque/dev/golang"

GOPROXY=""

GORACE=""

GOROOT="/usr/local/go"

GOTMPDIR=""

GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"

GCCGO="gccgo"

CC="gcc"

CXX="g++"

CGO_ENABLED="1"

GOMOD=""

CGO_CFLAGS=""

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS=""

PKG_CONFIG="pkg-config"

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build391546525=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Attempt to download the latest version of the AWS Go SDK, inadvertently mistyping the name

go get github.com/aws/aws-go-sdk@latest

The actual repository path is https://github.com/aws/aws-sdk-go, so the command failing is correct behavior.

What did you expect to see?

As error message stating that the import path github.com/aws/aws-go-sdk is invalid.

What did you see instead?

An error message about not being able to read "Username" and a link to information about private repositories

go get github.com/aws/aws-go-sdk@latest: git ls-remote -q https://github.com/aws/aws-go-sdk in /home/codewilling/dylan.bourque/dev/golang/pkg/mod/cache/vcs/d17433d3d37a4277c59cbf405fe09ca63188d440a697cdf310f37325d812006f: exit status 128:
    fatal: could not read Username for 'https://github.com': terminal prompts disabled
If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.

[dylan-bourque]

For a little more context, because the error message very specifically refers to private repositories, I spent over an hour researching causes for the "terminal prompts disabled" and A/B testing my credentials against my coworkers (I have 2FA enabled and he doesn't) when the actual issue turned out to be a mis-typed package/module path.

I understand that this is apparently standard Git behavior, but for me it was definitely an ineffective user experience.

[thepudds]

Wanted to briefly add that @dylan-bourque is not the first person to chase a red herring based on the contents of the current error message.

I don't know how easy it is for cmd/go to differentiate between a mistyped path vs. a private repo, but one simple improvement could be to add one more sentence or phrase to the current message, without any new logic for differentiating additional cases. For example, perhaps something like "Check the import path was entered correctly".

In general, dealing with private repositories is a bit of a pain point and often hits people when they are new to Go, so some amount of additional friendliness here might be warranted.

[bcmills]

I don't know how easy it is for cmd/go to differentiate between a mistyped path vs. a private repo

For repos hosted on github.com, it is more-or-less impossible. (Contrast #25982.)

However, see also #30748. Perhaps we can coax git into giving us a more helpful error message, or detect the https URL and try it ourselves to see if we can get something intelligible.

[theckman]

Maybe the error could indicate that it assumed you don't have permission, and that you should make sure you spelled it correctly? That might get kind of wordy, but I am struggling to see a different path forward.

The issue here is that GitHub is rightfully protecting against information disclosures, which sucks for us. 😂

[theckman]

Random thought: if we put error codes in these sorts of errors strings, people can read a more verbose explanation in an online knowledge base. Would avoid a lengthy error explanation, and allow us to give users actionable troubleshooting steps.

[dylan-bourque]

Definitely don't have any empirical proof, but my gut says that a typo in the module path is probably more likely than misconfigured credentials for a private repo. I would probably argue for mentioning the bad path possibility first.

[gopherbot]

Change https://golang.org/cl/174179 mentions this issue: cmd/go: say to confirm import path when it's not found