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

Import path resolution does not honour GO15VENDOREXPERIMENT #10

Open
vdobler opened this issue Sep 14, 2015 · 12 comments
Open

Import path resolution does not honour GO15VENDOREXPERIMENT #10

vdobler opened this issue Sep 14, 2015 · 12 comments

Comments

@vdobler
Copy link

vdobler commented Sep 14, 2015

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

@kisielk
Copy link
Owner

kisielk commented Sep 14, 2015

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 :)

@kisielk
Copy link
Owner

kisielk commented Sep 22, 2015

The general solution for this issue is being discussed in golang/go#12278

@tv42
Copy link

tv42 commented Feb 16, 2016

golang/go#12278 is closed and as a comment there suggests, godepgraph works with vendor/ if built with Go 1.6.

@mappu
Copy link

mappu commented Jul 11, 2016

I have built godepgraph with go1.7rc1, and it is unable to find a package that exists within a vendor directory.

@kisielk
Copy link
Owner

kisielk commented Dec 2, 2016

@paulbuis what happened to your comment? I got it via email but it isn't here.

@paulbuis
Copy link
Contributor

paulbuis commented Dec 5, 2016 via email

@eldondevcg
Copy link

Hi, this still doesn't seem to be working with vendored paths of dependencies as of go 1.8.3

@kisielk
Copy link
Owner

kisielk commented May 31, 2017

@eldondevcg can you provide an example repo?

@eldondevcg
Copy link

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.

@davcamer
Copy link
Contributor

davcamer commented Feb 5, 2018

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.

@davcamer
Copy link
Contributor

davcamer commented Feb 5, 2018

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?

@kisielk
Copy link
Owner

kisielk commented Feb 6, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants