Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: do not lookup "parent" modules automatically to resolve imports #33568

Open
rsc opened this issue Aug 9, 2019 · 8 comments
Open

cmd/go: do not lookup "parent" modules automatically to resolve imports #33568

rsc opened this issue Aug 9, 2019 · 8 comments

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Aug 9, 2019

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.

/cc @bcmills @jayconrod

@rsc rsc added this to the Go1.14 milestone Aug 9, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Aug 9, 2019

Nested modules in general are rare enough that I would be fine with a special-case to avoid this lookup.

@mvdan

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented Aug 9, 2019

I seem to remember a recent issue from @myitcv, where he reported that the go tool was incorrectly trying to find a myitcv.io module.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Aug 9, 2019

On the other hand, if we get rid of the finding chatter (#26152), is it actually that harmful to search for other modules? Those lookups should complete quickly anyway.

@myitcv

This comment has been minimized.

Copy link
Member

@myitcv myitcv commented Aug 12, 2019

@mvdan the example I had was actually with github.com in #33351

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 28, 2019

Should we do the same for “child” modules? (If you import rsc.io/tmp/x/foo instead of rsc.io/tmp/x/boo, should we try to resolve the module rsc.io/tmp/x/boo?)

If not, why is it more important to suppress the parent lookup than the child?

@seh

This comment has been minimized.

Copy link
Contributor

@seh seh commented Oct 28, 2019

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.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 28, 2019

@seh, could you open a separate issue for the hang? Even if we do an unnecessary lookup, it's supposed to complete quickly.

@seh

This comment has been minimized.

Copy link
Contributor

@seh seh commented Oct 28, 2019

Please see #35209.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.