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 mod tidy removes an in-use indirect dependency from go.mod #27664

Closed
zombiezen opened this issue Sep 13, 2018 · 9 comments
Closed

cmd/go: go mod tidy removes an in-use indirect dependency from go.mod #27664

zombiezen opened this issue Sep 13, 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

@zombiezen
Copy link
Contributor

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

go version go1.11 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/light/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/light"
GOPROXY=""
GORACE=""
GOROOT="/home/light/sdk/go1.11"
GOTMPDIR=""
GOTOOLDIR="/home/light/sdk/go1.11/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/light/src/github.com/google/go-cloud/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build947809198=/tmp/go-build -gno-record-gcc-switches"

It should be noted I'm running with GO111MODULE=on.

What did you do?

export GO111MODULE=on
git clone https://github.com/google/go-cloud.git
cd go-cloud
git checkout 64759c9ac3d4068c1e322814b088ba08a8ee360f
go mod tidy

What did you expect to see?

go mod tidy keeps gopkg.in/yaml.v2, an indirect dependency.

What did you see instead?

go mod tidy removes gopkg.in/yaml.v2 from go.mod, but not from go.sum.

Intriguingly, running go mod why gopkg.in/yaml.v2 yields:

# gopkg.in/yaml.v2
github.com/google/go-cloud/internal/testing/replay
github.com/dnaeon/go-vcr/cassette
gopkg.in/yaml.v2

/cc @bcmills
@zombiezen zombiezen mentioned this issue Sep 13, 2018
Closed
@bcmills
Copy link
Contributor

bcmills commented Sep 13, 2018

Do the other dependencies in the go.mod file imply any version of gopkg.in/yaml.v2?

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

github.com/dnaeon/go-vcr seems to, as it includes Gopkg.{lock,toml}. But it was my understanding/expectation that go mod tidy should include all indirect dependencies now, regardless of whether they could be inferred from other dependencies. (I forget where I gained this notion.)

@bcmills
Copy link
Contributor

bcmills commented Sep 13, 2018

No, go mod tidy includes

  • all of the direct dependencies, plus
  • the subset of indirect dependencies that have been upgraded past their otherwise-implied versions.

@bcmills
Copy link
Contributor

bcmills commented Sep 14, 2018

I think this is working as designed, but please reopen if you disagree.

@bcmills bcmills closed this as completed Sep 14, 2018
@zombiezen
Copy link
Contributor Author

Very possibly. I could have sworn @rsc said that a go.mod file after go mod tidy would reflect all the dependencies (so you wouldn't have to run go list etc.), but I can't find a citation now.

@leighmcculloch
Copy link
Contributor

leighmcculloch commented Sep 11, 2019 •
edited

@bcmills Could you elaborate on what you mean by otherwise-implied versions? I don't understand what that means, what is an implied version in the context of minimal version selection?

I'm interested in this because I'm seeing this same thing happen specifically with the same yaml package. When I was dependent on github.com/stretchr/testify@976c720a22c8 my go.mod has gopkg.in/yaml.v2 v2.2.2 // indirect in it. When I upgrade to github.com/stretchr/testify@v1.4.0 the yaml lines is removed from go.mod, but remains in go list -m all output.

(I'm seeing this happen in stellar/go#1739.)

@leighmcculloch leighmcculloch mentioned this issue Sep 11, 2019
Merged
@bcmills
Copy link
Contributor

bcmills commented Sep 11, 2019

@leighmcculloch, github.com/stretchr/testify v1.4.0 explicitly requires gopkg.in/yaml.v2 v2.2.2 (here).

In contrast, github.com/stretchr/testify 976c720a22c8 does not even have a go.mod file, so it imposes no requirements on the module graph, and your own module's go.mod file has to fill in // indirect entries for the missing dependencies.

@leighmcculloch
Copy link
Contributor

@bcmills Thanks, that makes a lot of sense. In theory then as modules become the norm if all modules were to have a go.mod file, no go.mod file would have an // indirect entry? And this also is the reasoning behind why it's important for us to use go list -m all and go mod graph to validate what dependencies we have?

@bcmills
Copy link
Contributor

bcmills commented Sep 11, 2019

Over time the // indirect entries should drop to only those requirements that are actually increased by the main module. And yes, this is why it's important to use go list or go mod graph instead of treating the go.mod file as a complete list of dependencies.

@golang golang locked and limited conversation to collaborators Sep 10, 2020
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
4 participants
@zombiezen @leighmcculloch @bcmills @gopherbot