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: consistently defer module path checks (including major-version matching) until import or build-list resolution #31662

Open
bcmills opened this issue Apr 24, 2019 · 2 comments

Comments

Projects
None yet
3 participants
@bcmills
Copy link
Member

commented Apr 24, 2019

At the moment, we validate that the major version through which a module was resolved matches the major-version suffix of the path declared in its go.mod file.

However, we perform that validation only sporadically (#31428), the resulting failure message (if any) can be difficult to understand in context (#30499, #30636), and a mismatch — even one involving mismatched major-version components — isn't even obviously correct if the module is involved in a replace directive (#26904, #27171 (comment)).

I suspect that we should simply not validate module paths at all when fetching a module, and instead do the validation consistently only at loading time (when we resolve explicit package imports).

At that point:

  • If a module is used to replace the source code of another module, we should ensure that its path — including the major-version component — matches the module whose code it replaces.
    • Due to existing replace usage, we might need to relax this to allow the module path to also match the path and version from which the source code was fetched, but ideally only if the go.mod file specifies go 1.12 or earlier.
  • If a module is used as an alias from another module path and version (#26904), then we should resolve it at the path to which the alias points during package loading, and thus the module path and major version should match that path (and the major version at which it is required).
  • If a module is downloaded using go mod download, we don't know how it is going to be used, and thus should not validate anything about its path.

CC @rsc @jayconrod @heschik @hyangah @katiehockman @leitzler @tbpg

@tbpg

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

If a module is downloaded using go mod download, we don't know how it is going to be used, and thus should not validate anything about its path.

Can we validate a given module's path and version (with an explicit go.mod) to see if there is a mis-matched major version?

@bcmills

This comment has been minimized.

Copy link
Member Author

commented Apr 30, 2019

Can we validate a given module's path and version (with an explicit go.mod) to see if there is a mis-matched major version?

I don't think so, no. It seems entirely reasonable to replace, say, github.com/utensil/spoon/v25 with utensil.dev/fork at v1.0.0, since the two modules have otherwise-distinct import paths and the renaming may have the explicit goal of resetting the major-version numbering.

@bcmills bcmills changed the title cmd/go: consistently defer module path checks (including major-version matching) until import resolution cmd/go: consistently defer module path checks (including major-version matching) until import or build-list resolution May 6, 2019

@bcmills bcmills added this to the Go1.13 milestone May 14, 2019

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.