Go-github: go get <package> not working

[apraveen25]

go get github.com/google/go-github/tree/v32.1.0/github

or

go get github.com/google/go-github/v32/github

package github.com/google/go-github/tree/v32.1.0/github: cannot find package "github.com/google/go-github/tree/v32.1.0/github" in any of:
/usr/local/go/src/github.com/google/go-github/tree/v32.1.0/github (from $GOROOT)
/Users//go/src/github.com/google/go-github/tree/v32.1.0/github (from $GOPATH)

[gmlewis]

Please try:

go get -u github.com/google/go-github/...

[chughpiyush]

@gmlewis Can we close old and inative issues like this and/or #1467 ?

Is there some minimum time for which an issue needs to remain open, post which only it can be marked as "inactive" and then closed ?

[gmlewis]

Yes, @chughpiyush - this can be closed. I try to leave them open for a short time to give the people a chance to respond with more questions, comments, or clarifications, but I have not been diligent about cleaning up. Periodically I run through all the issues and close them all out, but feel free to comment on old/obsolete issues when you find them, and I'll close them out... like you did here.

Thank you!

Closing issue as obsolete.

[ttacon]

I know that this is closed, so my apologies if it's not appropriate to comment on this thread, but I thought I'd share a bit of context as to what is likely going on here since I found it interesting (I ran into a similar issue), for any other future wayfarers.

This looks as though it is occurring due to the use of gopher flakes at the root of the package because of the usage of the v32 version of this package inside the nested scrape module, which is using go modules. This only happens when you yourself are not using go modules in the directory from which you call go get from. This is because, when not using go modules in the calling directory, go get recurses into the scrape subpackage, determines that it needs to pull down the v32 version, but does not understand this, and so reports this issue at that point.

As such, if you're not using go modules or calling go get not from a directory using them, and so are pulling this down to your $GOPATH, you'll need to specify the /github subpackage, a la go get -u github.com/google/go-github/github/... which will then work.

[gmlewis]

Very interesting! Thank you, @ttacon !

@willnorris and @dmitshur might be interested in this.

[gmlewis]

I'm discovering that other people are running across this same issue, and it looks like more investigation is needed to fix the issue involving the "scrape" subpackage, so I'm going to open this issue again.

Any volunteers are welcome to work on this. Ideally, go get -u github.com/google/go-github/... would work again without having to jump through any hoops.

[dmitshur]

@gmlewis To make progress on this issue, it would help to provide more information about what issue people are running into. The original issue report was trying to go get an import path that does not exist in GOPATH mode, so an error is the correct behavior.

In module mode, go get -u github.com/google/go-github/... works without errors using Go 1.15.7:

$ cd $(mktemp -d)
$ go mod init m.test
$ go get -u github.com/google/go-github/...
go: found github.com/google/go-github/... in github.com/google/go-github v17.0.0+incompatible
go: finding module for package google.golang.org/appengine/log
go: finding module for package golang.org/x/crypto/ssh/terminal
[...]
$ echo $?
0
$ cat go.mod
module m.test

go 1.15

require (
    github.com/golang/protobuf v1.4.3 // indirect
    github.com/google/go-github v17.0.0+incompatible // indirect
    github.com/google/go-querystring v1.0.0 // indirect
    golang.org/x/crypto v0.0.0-20201221181555-eec23a3978ad // indirect
    golang.org/x/net v0.0.0-20210119194325-5f4716e94777 // indirect
    golang.org/x/oauth2 v0.0.0-20210126194326-f9ce19ea3013 // indirect
    golang.org/x/sys v0.0.0-20210124154548-22da62e12c0c // indirect
    golang.org/x/term v0.0.0-20201210144234-2321bbc49cbf // indirect
    google.golang.org/appengine v1.6.7 // indirect
)

However, go get -u github.com/google/go-github/... is not a command that's very useful to run, as module mode users should use v33 and not v17. A more useful command would be go get github.com/google/go-github/v33/github@latest:

$ cd $(mktemp -d)                                     
$ go mod init m.test                                  
go: creating new go.mod: module m.test
$ go get github.com/google/go-github/v33/github@latest
go: found github.com/google/go-github/v33/github in github.com/google/go-github/v33 v33.0.0
$ cat go.mod
module m.test

go 1.15

require github.com/google/go-github/v33 v33.0.0 // indirect

[gmlewis]

Thank you, @dmitshur - I was working with someone who attempted to perform

go get -u github.com/google/go-github/v32

and the command failed. Having to add "/github@latest" to the end seems like a pain, does it not (or at the very least, it is non-intuitive).

Hmmm... I see that we don't have "Installation" instructions in the README.md... maybe this is all we need to address this issue?

[dmitshur]

That command works for me too:

$ cd $(mktemp -d)
$ go mod init m.test                                  
$ go get -u github.com/google/go-github/v32
go: downloading github.com/google/go-github/v32 v32.1.0
go: github.com/google/go-github/v32 upgrade => v32.1.0
$ echo $?
0
$ cat go.mod
module m.test

go 1.15

require github.com/google/go-github/v32 v32.1.0 // indirect

The "@latest" suffix can be omitted, I included it to make the version explicit.

Adding an "Installation" section to the README sounds like a good idea. I'm happy to review a PR for it. (An example of such a section can be found in the READMEs of blackfriday v1 and blackfriday v2.)

[gmlewis]

OK, great... thanks for testing this out, @dmitshur - I'm glad it worked... I'm not sure what was going wrong before.

Perfect. I'll open this issue up as a "good first issue" "enhancement" and open it up to volunteers.

For anyone who would like to take on this issue, here is what we need:

Adding an "Installation" section to the README sounds like a good idea. I'm happy to review a PR for it. (An example of such a section can be found in the READMEs of blackfriday v1 and blackfriday v2.)