-
Notifications
You must be signed in to change notification settings - Fork 90
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
Comments
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 |
golang/go#12278 is closed and as a comment there suggests, godepgraph works with |
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:[email protected]]
Sent: Friday, December 02, 2016 4:48 PM
To: kisielk/godepgraph <[email protected]>
Cc: Buis, Paul <[email protected]>; Mention <[email protected]>
Subject: Re: [kisielk/godepgraph] Import path resolution does not honour GO15VENDOREXPERIMENT (#10)
@paulbuis<https://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 GitHub<#10 (comment)>, or mute the thread<https://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:
For example, I get the following output from the above:
These packages are all vendored, used, and appear on the graph, but with no incoming edges. This is happening because the 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 |
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
The text was updated successfully, but these errors were encountered: