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: get can't fetch packages sources without dots in the base name #6520

msiebuhr opened this Issue Oct 1, 2013 · 7 comments


None yet
5 participants

msiebuhr commented Oct 1, 2013

What steps will reproduce the problem?
1. Run go get -x localhost/foo.git
2. Run go get -x

What is the expected output?
The output of the two commands should match (except hostname/ip difference).

What do you see instead?
The command that fetches from localhost fails (unrecognized import path), while the one
that explicitly gets the loopback IP succeeds.

Which version are you using?  (run 'go version')
go version devel +664c8763de42 Tue Oct 01 11:24:24 2013 +1000 linux/amd64

This also breaks imports from file-system paths, ie

    > go get shared/go/foo.git

Even though it works with a dot in the base name:

    > go get -x
    git clone /home/$USER/Source/go/src/

(Go get clearly tries to fetch from the file-system too, where having a dot in the path
isn't all that usual.)

This comment has been minimized.


adg commented Oct 2, 2013

Comment 1:

The "go get"-able import paths are supposed to be the host and path part of a
broadly-available URL. And that is supposed to make them unique. I'm not sure that we
want this.

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.


This comment has been minimized.


msiebuhr commented Oct 2, 2013

Comment 2:

Again, at least for git, it tries to use the given URL as a relative file-system path,
which is neither broadly available nor unique.
From reading vcs.go and get.go, the flow roughly reads like this:
 1. Remote schemas are tried when repoRootForImportPath() (whic doesn't return an error despite not finding anything...)
 2. No result? Then it must be the first element in $GOPATH
 3. Call vcs.create() on the folder to import the package. As it expects it to be a local package, the remote path is prefixed by $GOPATH[0]. In the case of GIT, the clone-command exits with status 128, thus making go get fail as a whole.
On a side note, get.go's downloadPackage() has a code (roughly) on the form
  if x != "" {
  } else {
  if x == "" {
which looks like the else and second if-statement should be catenated together. Should I
submit a change-request?

This comment has been minimized.


rsc commented Nov 27, 2013

Comment 3:

Labels changed: added go1.3maybe.


This comment has been minimized.


rsc commented Dec 4, 2013

Comment 4:

Labels changed: added release-none, removed go1.3maybe.


This comment has been minimized.


rsc commented Dec 4, 2013

Comment 5:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015


This comment has been minimized.


ysmolsky commented Nov 12, 2018

I am triaging it again.

Design of "go get" is about downloading packages from remote internet hosts, it means a domain with dot. If one wants to handle this for the local hostnames then it is possible to use local hostnames with a dot.

I am not sure that we want to handle this case on the side of go get because the proposed behaviour is rather an exception to the rule.

ping @msiebuhr


This comment has been minimized.

gopherbot commented Dec 12, 2018

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.)

@gopherbot gopherbot closed this Dec 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment