Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: do not lookup "parent" modules automatically to resolve imports #33568
One of the most annoying missteps the go command makes is when you mistype an import path in your own module and it goes looking for parent modules that might provide the import. In general that's fine, but I think automatic download and search of parents of the main module should be disabled - it's almost always a typo, and if not the user can run go get explicitly.
For example if I am in module rsc.io/tmp/x and import rsc.io/tmp/x/foo instead of rsc.io/tmp/x/boo, it should not try to download rsc.io/tmp and rsc.io to find rsc.io/tmp/x/foo.
I had a difficult Sunday trying to figure out why go build suddenly stopped working for me, and @bcmills was kind enough to point me here, once I could explain well enough what went on. Several problems came together to blind me to the cause.
I've been writing a Go module on my computer, but I have not committed any of the source to a remote Git repository yet. It's committed locally, but I haven't pushed it elsewhere.
At one point I created a package within this module, and I wrote an import statement to import that package into another package. Then I decided to delete that first package; I deleted the directory, but I neglected to remove the import statement from the other package that was depending on it.
At this point, when I would run go build, it would hang indefinitely, with no output. Running go build -v showed that it was trying to fetch this missing package first from the public Go proxy, and then via HTTP, then with the git tool over SSH. Since my machine lacked the proper Git configuration to allow go get to authenticate properly against the remote Git repository (it needs a particular user name for use with SSH), go get couldn't get Git to authenticate. It would retry several times, and then just hang.
All of this surprised me. I had assumed that if I'm editing files within a dominating module file, then the Go tools would trust that all of the pertinent code is here on my own disk. Even with my errant package import statement referring to a nonexistent package below the module path, I still didn't expect the Go tools to think that package would be available "out there." I expected my own disk content to be the source of truth.