x/vgo: missing dependendency in go.mod file #25371
Comments
bcmills
changed the title
|
This issue occured if your project and one of your imports have a common dep, and the version is also equal. In your codebase,
|
|
As @oiooj notes, the You should find that We certainly do need to work on some concise documentation for these sorts of properties, but I think that's a separate matter from this issue itself. Please feel free to reopen if you disagree. |
|
Actually, @bcmills realized that the build list algorithm assumes that direct dependencies are listed explicitly in go.mod, so we'll start doing that, even when the result is not minimal. Will send a CL probably tomorrow. |
|
Change https://golang.org/cl/121304 mentions this issue: |
A cleanup pass in mvs.BuildList discards modules that are not reachable in the requirement graph as satisfied for this build. For example, suppose: A -> B1, C1 B1 -> D1 B2 -> nothing C1 -> nothing D1 -> nothing D2 -> nothing The effective build list is A, B1, C1, D1 (no cleanup possible). Suppose that we update from B1 to B2. The effective build list becomes A, B2, C1, D1, and since there is no path through those module versions from A to D, the cleanup pass drops D. This cleanup, which is not in https://research.swtch.com/vgo-mvs, aims to avoid user confusion by not listing irrelevant modules in the output of commands like "vgo list -m all". Unfortunately, the cleanup is not sound in general, because there is no guarantee all of A's needs are listed as direct requirements. For example, maybe A imports D. In that case, dropping D and then building A will re-add the latest version of D (D2 instead of D1). The most common time this happens is after an upgrade. The fix is to make sure that go.mod does list all of the modules required directly by A, and to make sure that the go.mod minimizer (Algorithm R in the blog post) does not remove direct requirements in the name of simplifying go.mod. The way this is done is to annotate the requirements NOT used directly by A with a known comment, "// indirect". For example suppose A imports rsc.io/quote. Then the go.mod looks like it always has: module m require rsc.io/quote v1.5.2 But now suppose we upgrade our packages to their latest versions. Then go.mod becomes: module m require ( golang.org/x/text v0.3.0 // indirect rsc.io/quote v1.5.2 rsc.io/sampler v1.99.99 // indirect ) The "// indirect" comments indicate that this requirement is used only to upgrade something needed outside module m, not to satisfy any packages in module m itself. Vgo adds and removes these comments automatically. If we add a direct import of golang.org/x/text to some package in m, then the first time we build that package vgo strips the "// indirect" on the golang.org/x/text requirement line. If we then remove that package, the requirement remains listed as direct (the conservative choice) until the next "vgo mod -sync", which considers all packages in m and can mark the requirement indirect again. Algorithm R is modified to be given a set of import paths that must be preserved in the final output (all the ones not marked // indirect). Maintenance of this extra information makes the cleanup pass safe. Seeing all directly-imported modules in go.mod and distinguishing between directly- and indirectly-imported modules in go.mod are two of the most commonly-requested features, so it's extra nice that the fix for the cleanup-induced bug makes go.mod closer to what users expect. Fixes golang/go#24042. Fixes golang/go#25371. Fixes golang/go#25969. Change-Id: I4ed0729b867723fe90e836c2325f740b55b2b27b Reviewed-on: https://go-review.googlesource.com/121304 Reviewed-by: Bryan C. Mills <bcmills@google.com>
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.10.2 darwin/amd64 vgo:2018-02-20.1
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?GOARCH="amd64"
GOOS="darwin"
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
Using this project
https://github.com/ardanlabs/service
I added an empty go.mod file at the root of the project.
I ran the
vgo buildcommandOnce that was done, the
go.modfile contained the followingWhat did you expect to see?
There is a dependency in my vendor folder that is missing from the
go.modfile that is being used.github.com/openzipkin/zipkin-goI expected to see that in the
go.modfile.When I run the
vgo list -mcommand I do see this in the list.What did you see instead?
I just expected all my vendored dependencies to show up in the
go.modfile.The text was updated successfully, but these errors were encountered: