x/vgo: replace command appears to confuse vgo list #25427
Comments
|
I appreciate my original description was not very clear, so I'll give a more concrete example: We have 3 initial modules;
We then modify If we then run Which suggests that we're no longer depending on I would not expect |
|
More info that might be helpful that I just noticed is that if in the previous example we remove Note that |
jamie-digital
changed the title
|
In this situation is C listed in your top-level go.mod file explicitly? List will include anything from the go.mod even if there is no import of it. |
agnivade
added
the
WaitingForInfo
|
No, C isn't listed in go.mod. Another thing I noticed that might help in debugging is that |
|
Edit: See next comment |
|
I'm afraid I've not been able to make a particularly minimal reproduction, but I've removed all of the private code and published a new repo https://github.com/jamie-digital/vgo-list-m-example . If you go into the example package you should get the following behaviour: Note that I'm sorry the example is so complex. I've removed github.com/jamie-digital/a as it didn't reproduce the issue. |
agnivade
removed
the
WaitingForInfo
|
Thanks for the test case. I think vgo is working properly. I have some pending changes to expose the module graph, and if I try them on your test repo: That is, github.com/aws/aws-lambda-go is requiring github.com/pmezard/go-difflib, so it is correct to list it in the overall module list. It's also true that the module is not imported by anything in the aws-lambda-go repo, but the aws-lambda-go repo's Gopkg.lock mentions pmezard/go-difflib, and so we include it in the generated go.mod. Once aws-lambda-go converts to a native go.mod, they would presumably drop the explicit mention of pmezard/go-difflib, and then your test repo (if updated to use the new aws-lambda-go) would similarly drop it from the vgo list -m output. |
|
That makes sense. I look forward to the graph tool! |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.10 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"
GOBIN=""
GOCACHE="/path/to/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/path/to/gopath/go"
GORACE=""
GOROOT="/path/to/go"
GOTMPDIR=""
GOTOOLDIR="/path/to/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
What did you do?
I used the
replacecommand in mygo.modfile to replace a particular module with a version I had forked. One of the changes I made in the forked version was to remove some unwanted dependencies. The module being replaced was the only source of these particular dependencies.What did you expect to see?
I expected that
vgo list -mwould no longer list the dependencies mentioned above as the module replacement resulted in them no longer being dependencies of the build. Note thatvgo list -mdid pick up the replacement itself. Runningvgo build -a -vdid not list the dependencies, so I'm pretty sure they're not actually being used, butvgo list -mstill shows them which is confusing.The text was updated successfully, but these errors were encountered: