Open vdobler opened 9 years ago
A similar request exists for kisielk/errcheck#75
One problem is there's no API available for loading vendored packages at the moment, it seems the only support is directly in cmd/go so I'd need to dissect that code and reuse the logic (probably via kisielk/gotool). I was kind of hoping to just wait it out till it's an official feature and then maybe that work wouldn't be necessary :)
The general solution for this issue is being discussed in golang/go#12278
https://github.com/golang/go/issues/12278 is closed and as a comment there suggests, godepgraph works with vendor/
if built with Go 1.6.
I have built godepgraph with go1.7rc1, and it is unable to find a package that exists within a vendor directory.
@paulbuis what happened to your comment? I got it via email but it isn't here.
I deleted the comment when I realized the issue did not apply to the version of godepgraph that you had on github. I’ve modified the your code for a special-purpose project (where my code invokes a method that replaces your main method) and my modified version is failing on a vendored project. However, the problem was not reproducible when I went back and re-tried with your code as a standalone program. My program needs to find dependency graphs multiple times, so I’ve converted your package var block into a struct and have methods on that struct. I must not be initializing them right or I made some unintentional bug-inducing change.
I apologize for commenting on github.com before making a more thorough investigation of my problem.
I thought the map maintained in the program was purely on package names (the full name including slashes) and not on the full file path to the src/pkg files, which would have been consistent with what I was seeing. I was getting messages that foo.a was not found in the directory one would expect to find it in if it was not vendored, but that does not happen when I run the godepgraph command generated directly from your source code.
From: Kamil Kisiel [mailto:notifications@github.com] Sent: Friday, December 02, 2016 4:48 PM To: kisielk/godepgraph godepgraph@noreply.github.com Cc: Buis, Paul 00pebuis@bsu.edu; Mention mention@noreply.github.com Subject: Re: [kisielk/godepgraph] Import path resolution does not honour GO15VENDOREXPERIMENT (#10)
@paulbuishttps://github.com/paulbuis what happened to your comment? I got it via email but it isn't here.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/kisielk/godepgraph/issues/10#issuecomment-264571503, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD9F48TeEzHHAdIWYCyEWqKd7iGfOYRxks5rEJIWgaJpZM4F8vWB.
Hi, this still doesn't seem to be working with vendored paths of dependencies as of go 1.8.3
@eldondevcg can you provide an example repo?
It failed when I tried to run it against a repo that depends on the docker repo. I will try to come up with a concise reproducer if it seems to work for you.
With go1.9.2 I am seeing all vendored packages reported under $GOPATH/vendor, and they are shown as having dependencies on each other, although they do not.
After some investigation, it turns out the vendored packages shown in my .dot were imported, but no incoming edges were being rendered. I'll try to explain my understanding of how this is happening.
This branch is skpping the edge incoming to the vendored package:
impPkg := pkgs[imp]
if impPkg == nil || isIgnored(impPkg) {
debugf("Skipping imports because package is ignored: %v imported by %v was %v\n", imp, pkg.Name, impPkg)
continue
}
For example, I get the following output from the above:
Skipping imports because package is ignored: github.com/ianschenck/envflag imported by doge was <nil>
Skipping imports because package is ignored: github.com/pborman/uuid imported by context was <nil>
Skipping imports because package is ignored: golang.org/x/net/context imported by context was <nil>
Skipping imports because package is ignored: github.com/golang/protobuf/proto imported by dorpc was <nil>
These packages are all vendored, used, and appear on the graph, but with no incoming edges.
This is happening because the pkgs
map is keyed off of the package's .ImportPath
, which contains the vendor prefix. But the lookup in the condition is based on the importing package's .Imports
which do not include the vendor prefix. This is described in the comment for the IgnoreVendor
ImportMode
.
For the graph I'm trying to create at the moment, I'm going to hack around this based on the single, hard-coded vendor prefix that I know my code base uses. I'm not sure what a general-purpose fix could be here? Maybe splitting ImportPath on the string vendor
and taking the tail? Is vendor
now a reserved package name though?
Thanks for the patch @davcamer
I don't suppose you have a small example repo that could be added to .travis.yml to serve as a test?
If one uses vendored packages [1] in a folder "vendor" and sets GO15VENDOREXPERIMENT=1 godepgraph won't list the vendored ones, but the ones directly from GOPATH.
It would be cool if godepgraph could honour the GO15VENDOREXPERIMENT environment variable and resolve the packages like the go tool does.
[1] https://golang.org/s/go15vendor