/ go Public
cmd/go: loops without output when a module fetch via
git+ssh fails to authenticate
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
go version go1.13.3 darwin/amd64
Does this issue reproduce with the latest release?
This is the latest release available to me at time of writing.
What operating system and processor architecture are you using (
What did you do?
As described previously in #33568 (comment), I added a few new packages to an existing Go module. Let's call one of the new modules
dependency, and another that imports the first one
In file go.mod:
In file dependency/greet.go:
In file dependent/main.go:
Now, say that I decide that I don't need the dependency module anymore, and I delete the dependency directory, but I edit the dependency/main.go file such that I mistakenly leave that
importstatement in place:
Now, try to run go build to build the program in dependency.
In the main.go file above, the first import statement is no longer used, which is a problem that arises so frequently that our tools like goimports automatically remove such statements. I can't recall now whether triggering this problem required leaving use of that missing package in place.
What did you expect to see?
go build should fail quickly and print a message complaining that this dependency package does not exist within this module, ideally not looking anything up over the network, since the module is already defined locally in this source tree.
What did you see instead?
go build hangs, producing no output.
Running go build -v instead, we see output like the following:
go build -v output
In this case, it turns out that the SSH server requires a particular user name to authenticate, requiring an entry like the following in my ~/.gitconfig file:
With that in place, go build is able to complete its fetch attempt, and conclude that the dependency package truly does not exist, and prints a message like this:
More clear to me would be if go build had noted that there's no directory here called dependency, but we referred to it via that import path from that file.
The text was updated successfully, but these errors were encountered: