8000 cmd/go: should go get deduce semantic import versioning when GO111MODULE is off? · Issue #27430 · golang/go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

cmd/go: should go get deduce semantic import versioning when GO111MODULE is off? #27430

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
Closed
marwan-at-work opened this issue Aug 31, 2018 · 6 comments
Closed

cmd/go: should go get deduce semantic import versioning when GO111MODULE is off? #27430

marwan-at-work opened this issue Aug 31, 2018 · 6 comments
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Go1.12

Comments

@marwan-at-work
Copy link
Contributor
marwan-at-work commented Aug 31, 2018 •
edited
Loading

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
Copy link
Member
myitcv commented Aug 31, 2018

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

@bcmills bcmills added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Sep 22, 2018
@bcmills
Copy link
Contributor
bcmills 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
Copy link
Contributor
bcmills 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
Copy link
Contributor
bcmills 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
Copy link
Member
myitcv 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!

@bcmills bcmills mentioned this issue Nov 19, 2018
Closed
@rsc
Copy link
Contributor
rsc 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 as completed Nov 20, 2018
@golang golang locked and limited conversation to collaborators Nov 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
5 participants
@rsc @myitcv @bcmills @gopherbot @marwan-at-work
0