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: should go get deduce semantic import versioning when GO111MODULE is off? #27430

Closed
marwan-at-work opened this issue Aug 31, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@marwan-at-work
Copy link
Contributor

commented Aug 31, 2018

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

1.11

Does this issue reproduce with the latest release?

Yes

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

All

What did you do?

GO111MODULE=off go get github.com/google/go-github/v18/github

What did you expect to see?

Go downloads the library into my GOPATH ignoring the v8 suffix.

What did you see instead?

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

Summary

  1. Go's import paths are smart enough to ignore the v18 when GO111MODULE is turned off.
  2. go install is also smart enough to remove vX when installing a go binary.

What makes go-get an exception?

Impact

If things stay the same way, all libraries like github.com/google/go-github will have to have two instructions for their users to download their library. Something like this:

### Installation
With Go Modules: 
go get github.com/google/go-github/v18/github
import "github.com/google/go-github/v18/github" 

Without Go Modules: 
go get github.com/google/go-github/github
import "github.com/google/go-github/github"

Of course, you don't need to do go-get with Go Modules but the point is all the same: having two different installation/import instructions.

@myitcv myitcv added the modules label Aug 31, 2018

@myitcv myitcv added this to the Go1.12 milestone Aug 31, 2018

@myitcv

This comment has been minimized.

Copy link
Member

commented Aug 31, 2018

This is effectively the library equivalent of #24250 (from both an implementation and docs perspective)

@bcmills

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

I don't think this actually has much to do with #24250: that issue is about what happens in module mode (and does not modify GOPATH/src), whereas this one is about what happens in GOPATH mode (and doesn't really affect the semantics of module mode).

@bcmills

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

FWIW, there is already a difference in instructions: users of a library in module mode will generally not need to run go get at all. So the documentation would be more like:

### To use:
import "github.com/google/go-github/v18/github"

### To install:
(Only necessary if Go modules are not enabled.)
go get -u github.com/google/go-github/github
@bcmills

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

One final note: any change here would either require backports or introduce behavior in GOPATH mode that only affects versions of the go command that also support module mode. The latter option seems a little strange to me.

@myitcv

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

@bcmills

This is effectively the library equivalent of #24250

I don't think this actually has much to do with #24250:

I honestly can't tell you what I was thinking when I wrote that!

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2018

The module vs non-module import path magic is necessarily incomplete. You cannot use a go command in GOPATH mode and pretend to have full support for semantic import paths. The special case we added is limited, to avoid ambiguity. The limitation is:

In module-aware code (a .go file within a tree with a go.mod file), an unresolvable import with a version number will be tried again after removing the version number.

This does not apply to anything else but that special case. In particular it does not apply to any command line usage, not to go get, not to go list, not to go anything.

It's just not a goal to try to make GOPATH mode "more like" module mode. I think that will lead to more confusion than anything. The GOPATH-mode name for that package does not have a v18 in it.

@rsc rsc closed this Nov 20, 2018

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