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.

Sign up for GitHub

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

Jump to bottom

cmd/go: module-aware get x.go should not look up the host x.go #18533

Closed
KevinGimbel opened this issue Jan 6, 2017 · 14 comments
Closed

cmd/go: module-aware get x.go should not look up the host x.go #18533

KevinGimbel opened this issue Jan 6, 2017 · 14 comments
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@KevinGimbel
Copy link

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
Copy link
Contributor

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 cmd/go: Duplicate download for similar named repositories cmd/go: fail more explicitly on "go get" of a filename? Jan 6, 2017
@rsc
Copy link
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
Copy link
Contributor

davecheney commented Jan 7, 2017 via email

@ghost
Copy link

ghost commented Jan 7, 2017 •
edited by ghost

@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
Copy link
Contributor

davecheney commented Jan 7, 2017 via email

@ghost
Copy link

ghost 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
Copy link
Contributor

davecheney commented Jan 7, 2017 via email

@KevinGimbel
Copy link
Author

@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
Copy link
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
Copy link
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 Feedback is required from experts, contributors, and/or the community before a change can be made. label Jun 22, 2017
@rsc
Copy link
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
Copy link
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 cmd/go: fail more explicitly on "go get" of a filename? cmd/go: module-aware get x.go should not look up the host x.go Oct 25, 2018
@rsc
Copy link
Contributor

rsc commented Nov 28, 2018

Needs fix as described in previous comment.

@rsc rsc added the NeedsFix The path to resolution is known, but the work has not been done. label Nov 28, 2018
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 28, 2018
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@rsc rsc removed their assignment Jun 23, 2022
@seankhliao
Copy link
Member

I believe this is done

main » go version                    
go version devel go1.21-10ad6c91de1 Fri May 5 19:53:39 2023 +0000 linux/amd64

main » go get x.go                               
go: x.go: arguments must be package or module paths

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
10 participants
@bradfitz @davecheney @rsc @andybons @KevinGimbel @gulyasm @ianlancetaylor @bcmills @gopherbot @seankhliao