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

Jump to bottom

cmd/go: go install with getmode vendor and mod sync issue #26704

Closed
mfridman opened this issue Jul 31, 2018 · 9 comments
Closed

cmd/go: go install with getmode vendor and mod sync issue #26704

mfridman opened this issue Jul 31, 2018 · 9 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.12

Comments

@mfridman
Copy link

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

go version go1.11beta2 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

go mod -vendor
go mod -sync
go mod -verify

go install -getmode=vendor ./cmd/xyz

go mod -sync

What did you expect to see?

The go.mod to reflect the dependencies prior to running go install. Specifically, was expecting many indirect entries to remain the same.

What did you see instead?

Running the above removed many indirect entries from go.mod and replaced with latest available. E.g., this is one of the entries in go.mod prior to go install:

go.mod:

github.com/satori/go.uuid v1.1.0 // indirect

vendor/modules.txt:

# github.com/satori/go.uuid v1.1.0
github.com/satori/go.uuid

go install -getmode=vendor ./cmd/xyz removed the indirect entry for v1.1.0 from go.mod

then go mod -sync added v1.2.0 to go.mod:

github.com/satori/go.uuid v1.2.0 // indirect
@ianlancetaylor
Copy link
Contributor

CC @bcmills

@ianlancetaylor ianlancetaylor added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Aug 3, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Aug 3, 2018
@bcmills
Copy link
Contributor

bcmills commented Aug 3, 2018

I'm not able to reproduce this issue with the go command built from head.
Please try installing from source and see if you can reproduce the error. (Note that many of the mod subcommands have changed due to #26581.)

A complete repository that demonstrates it would be ideal: there may be some subtle interaction with the imports of your program (or the other packages in the module) that we cannot infer from the reported information.

$ cat cmd/xyz/xyz.go
package xyz

import _ "github.com/satori/go.uuid"

func main() {}

$ go mod init github.com/golang/go/issues/26704
$ go get github.com/satori/go.uuid@v1.1.0
$ go mod vendor

$ find vendor/
vendor/
vendor/github.com
vendor/github.com/satori
vendor/github.com/satori/go.uuid
vendor/github.com/satori/go.uuid/README.md
vendor/github.com/satori/go.uuid/.travis.yml
vendor/github.com/satori/go.uuid/uuid.go
vendor/github.com/satori/go.uuid/LICENSE
vendor/modules.txt

$ go list -m all
github.com/golang/go/issues/26704
github.com/satori/go.uuid v1.1.0

$ go mod tidy

$ go mod verify
all modules verified

$ go list -m all
github.com/golang/go/issues/26704
github.com/satori/go.uuid v1.1.0

$ go install -mod=vendor ./cmd/xyz

$ go list -m all
github.com/golang/go/issues/26704
github.com/satori/go.uuid v1.1.0

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 3, 2018
@mfridman
Copy link
Author

mfridman commented Aug 3, 2018

@bcmills Will try repro with head. Thanks for getting back.

@mfridman
Copy link
Author

mfridman commented Aug 3, 2018

(I'm using satori/go.uuid as an example, there are 30+ indirect items getting removed then re-added with latest tag available)

Will try and put together a public repro.

$ go version
go version devel +9594ba4fe5 Fri Aug 3 15:44:22 2018 +0000 darwin/amd64

$ go list -m all | grep satori
github.com/satori/go.uuid v1.1.0

$ go mod tidy

$ go mod verify
all modules verified

$ go list -m all | grep satori
github.com/satori/go.uuid v1.1.0

$ GOGC=off go install -v -mod=vendor ./cmd/xyz

$ git diff | grep satori
-       github.com/satori/go.uuid v1.1.0 // indirect

$ go list -m all
// satori does not appear in the output

$ go mod tidy
go: finding ... // satori does not appear in the output

$ git diff | grep satori
-	github.com/satori/go.uuid v1.1.0 // indirect
+	github.com/satori/go.uuid v1.2.0 // indirect
-github.com/satori/go.uuid v1.1.0 h1:B9KXyj+GzIpJbV7gmr873NsY6zpbxNy24CBtGrk7jHo=
-github.com/satori/go.uuid v1.1.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
+github.com/satori/go.uuid v1.2.0 h1:0uYX9dsZ2yD7q2RtLRtPSdGDWzjeM3TbMJP9utgA0ww=
+github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

@mfridman
Copy link
Author

mfridman commented Aug 3, 2018

@bcmills I've put together a contrived example.

I found it odd that go mod vendor pulls v1.1.0 of the satori pkg.

  • then running install (or build) completely removes the // indirect entry, presumably builds with v1.1.0
  • then go mod tidy pulls in the latest tagged v1.2.0 of satori pkg
  • then running go mod vendor rebuilds the vendor dir with v1.2.0
git clone git@github.com:mfridman/go-modules.git
cd go-modules

$ go version
go version devel +9594ba4fe5 Fri Aug 3 15:44:22 2018 +0000 darwin/amd64

$ go list -m all | grep satori
github.com/satori/go.uuid v1.1.0

$ go mod tidy

$ go mod verify
all modules verified

$ go list -m all | grep satori
github.com/satori/go.uuid v1.1.0

$ go mod vendor

$ cat vendor/modules.txt  | grep satori
# github.com/satori/go.uuid v1.1.0
github.com/satori/go.uuid

$ GOGC=off go install -v -mod=vendor

$ git diff | grep satori
-	github.com/satori/go.uuid v1.1.0 // indirect

$ go list -m all
// trimmed...

$ go mod tidy
go: finding gopkg.in/check.v1 latest

$ git diff | grep satori
-	github.com/satori/go.uuid v1.1.0 // indirect
+	github.com/satori/go.uuid v1.2.0 // indirect
-github.com/satori/go.uuid v1.1.0 h1:B9KXyj+GzIpJbV7gmr873NsY6zpbxNy24CBtGrk7jHo=
-github.com/satori/go.uuid v1.1.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
+github.com/satori/go.uuid v1.2.0 h1:0uYX9dsZ2yD7q2RtLRtPSdGDWzjeM3TbMJP9utgA0ww=
+github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=

$ go mod vendor

$ cat vendor/modules.txt | grep satori
# github.com/satori/go.uuid v1.2.0
github.com/satori/go.uuid

@mfridman
Copy link
Author

mfridman commented Aug 5, 2018

@gopherbot, please remove label waitingforinfo

@gopherbot gopherbot removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 5, 2018
@rsc
Copy link
Contributor

rsc commented Aug 9, 2018

Vendor is still written as though it has complete knowledge of the graph, like tidy, but it does not. So it must not fiddle with indirect tags.

@gopherbot
Copy link

Change https://golang.org/cl/128899 mentions this issue: cmd/go: fix go.mod corruption using -mod=vendor

@rsc
Copy link
Contributor

rsc commented Aug 9, 2018

My earlier diagnosis about vendor was wrong; go mod vendor is behavior correctly. The problem is go install -mod=vendor, which is incorrectly assuming it knows anything about the module graph and has any justification for updating go.mod. It does not.

@golang golang locked and limited conversation to collaborators Aug 10, 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 NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
5 participants
@rsc @ianlancetaylor @bcmills @mfridman @gopherbot