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

go.mod: non-transitivity of 'latest' or 'master' specifiers #33181

Closed
zx2c4 opened this issue Jul 19, 2019 · 5 comments

Comments

@zx2c4
Copy link
Contributor

commented Jul 19, 2019

If golang.org/example/b has in its go.mod require golang.org/example/a latest and golang.org/example/c has in its go.mod require golang.org/example/b v0.0.0-20190718085022-1eaf99633a99 or require golang.org/example/b latest, then building golang.org/example/c will fail with something like:

go: golang.org/example/b@v0.0.0-20190718085022-1eaf99633a99: parsing 
go.mod:6: invalid module version "latest": version must be of the form v1.2.3
go: error loading module requirements
@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

latest is not a semantic version: it is (at best) a tag or branch name, and should be resolved to an actual semantic version or pseudo-version whenever a go command is run within the golang.org/example/b module.

Is this a theoretical problem, or did you encounter this in a real-world scenario? If the latter, did someone commit a go.mod file without actually running, say, go test or go build on it?

@zx2c4

This comment has been minimized.

Copy link
Contributor Author

commented Jul 22, 2019

This is a "real-world scenario", except with the "someone" being me. I'm still a way's off from being able to tag stable versions, and I don't really want to have to bump go.mod in b every time a changes. Recently I wanted to start playing with a c use case, which depends on b, and I ran into this snag. The behavior I'd expect is for all of the latest markers and such to be resolved once on the first go build, similar to what happens when you only have a b depends on a with no c in the picture. The hard part about implementing this, I would imagine, is that when c depends on b, b's contents are supposed to be immutable, which means at present afaict there's no place to put a resolved go.mod for the intermediate b.

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 22, 2019

One of the design goals of modules is to enable fully-reproducible builds, and leaving label and branch-names such as latest unresolved would be antithetical to that goal.

You could leave a out of b's go.mod file entirely, in which case c would have to re-resolve it (and would resolve the latest version by default). However, it seems simpler to leave the dependency on a at whatever you tested b against: you can always upgrade above that explicitly in module c (by running go get golang.org/example/a within that module).

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 26, 2019

@zx2c4, does the above approach satisfy your use-case? (If not, what are the remaining problems?)

@gopherbot

This comment has been minimized.

Copy link

commented Aug 26, 2019

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@gopherbot gopherbot closed this Aug 26, 2019

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