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: module-aware get x.go should not look up the host x.go #18533

Open
kevingimbel opened this Issue Jan 6, 2017 · 13 comments

Comments

Projects
None yet
8 participants
@kevingimbel

kevingimbel commented Jan 6, 2017

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

go version go1.7.4 darwin/amd64

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

MacOS Sierra 10.12.1

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/kevingimbel/Development/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m7/zzw3lkfd03v0zrv0d_yvcrbh0000gn/T/go-build857722417=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

I tried to get a script I wrote from my personal GitHub Profile using go get github.com/kevingimbel/vhost.go

What did you expect to see?

I expected to get the source code from github.com/kevingimbel/vhost.go to download to $GOPATH/src/github/kevingimbel/vhost.go

What did you see instead?

Instead github.com/kevingimbel/vhost.go and github.com/kevingimbel/vhost were downloaded to $GOPATH/src/github/kevingimbel. The second one is a shell script which should not be downloaded when I specify the "url" github.com/kevingimbel/vhost.go.


Is this intended behaviour? Should go get look for similar names to what you specify, let's say in case of a typo? I expected it to only download one of the two repository, namely vhost.go which I specified.

My script itself is broken, too, because it searches for a package named vhost which does not exist. When I clone the repository with git to $GOPATH/src/github.com/kevingimbel and try to run it I get the following error:

$ go run vhost-cli.go
vhost-cli.go:5:2: cannot find package "github.com/kevingimbel/vhost/api" in any of:
        /usr/local/go/src/github.com/kevingimbel/vhost/api (from $GOROOT)
        /Users/kevingimbel/Development/go/src/github.com/kevingimbel/vhost/api (from $GOPATH)

When I rename the directory vhost.go to vhost it works as expected.

$ go run vhost-cli.go
2017/01/06 09:15:23 Successfully created file

What would be the best naming convention if two repositories under the same account have the "same" or similar name? To "fix" this I would need to re-name vhost.go to vhost and the shell script to something like vhost.sh. This might be an edge case but it should be documented somewhere since it can affect other users, too.

Might be related to #18484.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Jan 6, 2017

The go get command takes a package as its argument, not a filename.

I suspect something might be attempting to canonicalize your argument and removing the .go suffix.

In any case, it should probably have a better error message.

/cc @rsc

@bradfitz bradfitz added this to the Go1.9 milestone Jan 6, 2017

@bradfitz bradfitz changed the title from cmd/go: Duplicate download for similar named repositories to cmd/go: fail more explicitly on "go get" of a filename? Jan 6, 2017

@rsc

This comment has been minimized.

Contributor

rsc commented Jan 6, 2017

In the current model, go get foo (with no -u) means to install foo and any missing dependencies, but not update anything. So if you have foo already 'go get foo' and 'go install foo' are the same.

In general, you can list .go files instead of a package name and the go command will pretend they make up a package and do what you ask for them, for example build it or tell you information: go list -json x.go.

go get foo/bar/x.go means get all the dependencies needed by that file and then build and install the file. The install will fail since it doesn't know where to install it, but you didn't get that far.

All of this may be rethought this year, so I'm not inclined to make tweaks right now. The best solution is to change your repo name not to end in ".go". That's just not the convention and it's not going to work.

@davecheney

This comment has been minimized.

Contributor

davecheney commented Jan 7, 2017

@opennota

This comment has been minimized.

opennota commented Jan 7, 2017

@rsc

go get foo/bar/x.go means get all the dependencies needed by that file and then build and install the file.

Then this is somewhat underdocumented.

@davecheney

This comment has been minimized.

Contributor

davecheney commented Jan 7, 2017

@opennota

This comment has been minimized.

opennota commented Jan 7, 2017

@davecheney

It's not documented because it's wrong. Go get works on packages, not files.

Then go get should not reject any repos based on their suffix and should not attempt to trim that suffix.

@davecheney

This comment has been minimized.

Contributor

davecheney commented Jan 7, 2017

@kevingimbel

This comment has been minimized.

kevingimbel commented Jan 7, 2017

@rsc

The best solution is to change your repo name not to end in ".go". That's just not the convention and it's not going to work.

Would *-go be better then? Let's say you have a project which provides SDKs in multiple languages and each repo is named myproject-lang so myproject-go, myproject-javascript, myproject-scala, etc. - would this be an appropriate naming convention?

Is it documented anywhere that repos cannot end in .go?

In my opinion for the 1.9 release there should be a more verbose error message when downloading a package which ends on .go.

@gulyasm

This comment has been minimized.

Contributor

gulyasm commented Jan 7, 2017

I'm thinking: checking in runGet that the package names are "valid" before downloading. If any package name ends with .go, exit with meaningful error message.

Is it a good approach or it's too aggressive to fail if any package name is "wrong"?

@rsc

This comment has been minimized.

Contributor

rsc commented Jun 22, 2017

It's not documented because it's wrong. Go get works on packages, not files.

And when you name .go source files in place of a package, the command is operating on the package defined by those source files. See also "go build x.go y.go z.go", "go test x.go", and so on.

@rsc rsc modified the milestones: Go1.10, Go1.9 Jun 22, 2017

@rsc rsc added the NeedsDecision label Jun 22, 2017

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 1, 2017

Will keep in mind for next cycle.

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 1, 2017

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jul 6, 2018

@rsc

This comment has been minimized.

Contributor

rsc commented Oct 25, 2018

Module-aware get should just reject .go files on the command line. That will clear this up. We'll leave legacy GOPATH get alone until we remove it.

@rsc rsc changed the title from cmd/go: fail more explicitly on "go get" of a filename? to cmd/go: module-aware get x.go should not look up the host x.go Oct 25, 2018

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 28, 2018

Needs fix as described in previous comment.

@rsc rsc added the NeedsFix label Nov 28, 2018

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