cannot find package with 3 levels such as "github.com/golang/protobuf/proto"

[weaming]

godepgraph github.com/coreos/etcd | dot -Tpng -o godepgraph.png && imgcat godepgraph.png
2018/03/29 20:31:16 failed to import github.com/golang/protobuf/proto: cannot find package "github.com/golang/protobuf/proto" in any of:
	/usr/local/go/src/github.com/golang/protobuf/proto (from $GOROOT)
	/Users/weaming/go/src/github.com/golang/protobuf/proto (from $GOPATH)

[paulbuis]

The finding of packages in godepgraph is handled by the same functions used by the "go" command for compiling a package, so are you having the same problem when you run "go build github.com.coreos/etcd" ?? Specifically, as far as I can tell, godepgraph uses the "build environment" which looks at the binaries of the packages rather than the source of the packages, so you may need to use "go install" on the dependent packages first. I doubt it is related to the number of directory levels involved.

[weaming]

@paulbuis You correct me with that godepgraph uses the "build environment" which looks at the binaries of the packages rather than the source of the packages. I think it analysis to the source code. I will try someday again.

[paulbuis]

You might want to look at the "go list" command to get the raw textual data for a dependency graph that does not come from analyzing the binaries for a package. I'm currently using the "-json" option as in "go list -json ./..." for the package in the current directory and then parsing the output into an array of nodes for the dependency graph.

[kisielk]

yes, this package was written quite a long time ago and uses much more primitive methods of traversing the dependency graph than are now available in Go.

[weaming]

Tried and succeed just now. But the lines are too messy, any way to improve this?

[paulbuis]

I just published a re-work of godepgraph at https://github.com/paulbuis/golistdepgraph that draws on execing "go list -json" for each package to get the dependency information and output it in a similar GraphViz dot format. It isn't thoroughly tested quite yet. It is also a bit slow because an "exec" is much slower than invoking one of the standard library "ImportXXX" methods. However, it does seem to handle things like vendoring and missing package sources reasonably well.

[kisielk]

You could always just use a copy of the code of go list and bypass the exec and json steps. It should be much faster that way.