It's usefull when trying to analize a big project that contains external dependencies, and we need to trim down the graph a litte to understand it better.

Could we add a flag to enable delving into the dependencies of packages in the standard library, so that godepgraph can be used on those packages, too?

Uses the new isVendored() func to display vendored libraries in a different color than the application being graphed.

Bikeshed avoidance attempt: Yellow is not meant as a warning, but as a "separate path to the stdlib" since blue + yellow = green. It's a reach...

Example using github.com/stretchr/testify because it's a small project with a vendor directory on my machine.

Add flag to ignore the vendored packages. Works best with ignoring the stdlib too.

Adds isVendored() func checking for vendored libraries. Technically, it could be incorrect in a few edge cases, but I consider it an acceptable risk.

By default godepgraph will display packages in the standard library in the graph, though it will not delve in to their dependencies.

How do I turn this off?

The example graph does include the dependencies. How do you do that?

This standardizes vendored packages so that they can be found using the string from another package's .Imports list.

This addresses the issues I described in #10.

I believe vendor/ is a safe token to split on, based on this passage in the documentation:

Code below a directory named "vendor" is importable only by code in the directory tree rooted
at the parent of "vendor", and only using an import path that omits the prefix up to and including
the vendor element.

So that for svg output the link will be generated, for we can generate map file:

dot -Tcmapx -o file.cmapx file.dot

Using svg file in html:

<object type="image/svg+xml" data="file.svg"/>

Using png file in html:

<img src="file.png" usemap="#godep"/>
<map id="godep" name="godep">
<area shape="poly" id="node1"...

Hello -

I just cloned your project into my GitHub, & then tried to run it using your README guidance, & it doesn't work.

What am I doing incorrectly?

Here's the pertinent information:

$ pwd /Users/ajpowel/GitHub/godepgraph

s986572:godepgraph ajpowel$ ls -lah total 4312 drwxr-xr-x 8 ajpowel SANDIA\Domain Users 272B May 18 12:20 ./ drwxr-xr-x 9 ajpowel SANDIA\Domain Users 306B May 18 12:20 ../ drwxr-xr-x 13 ajpowel SANDIA\Domain Users 442B May 18 12:20 .git/ -rw-r--r-- 1 ajpowel SANDIA\Domain Users 1.0K May 18 12:20 LICENSE -rw-r--r-- 1 ajpowel SANDIA\Domain Users 1.8K May 18 12:20 README.md -rw-r--r-- 1 ajpowel SANDIA\Domain Users 2.1M May 18 12:20 example.png -rw-r--r-- 1 ajpowel SANDIA\Domain Users 6.9K May 18 12:20 example.svg -rw-r--r-- 1 ajpowel SANDIA\Domain Users 4.0K May 18 12:20 main.go

I don't even see an executable, or anything to build.

What am I missing here?

Many thanks for any guidance you can offer!

Best,

AJP

From https://go.dev/doc/go-get-install-deprecation :

Starting in Go 1.17, installing executables with go get is deprecated. go install may be used instead.

We use the version suffix @latest so that go install will ignore a go.mod in the cwd.

I feel that the codebase would benefit from some refactoring, specifically from moving most of the logic away from the main package, so it's also testable, but I suppose that's a task for another PR?

It would be very useful if it would be possible to run for executable sources.

Commonly I am trying to move all functionality in separate modules and I clue logic at executable sources. But godepgraph can't parse not imported source files.

As I have commonly 2 executable sources then I just rename main to somename and it works.

Hello!

$ go env                                                                              
GO111MODULE="on"
GOARCH="arm64"
GOBIN="/Users/anthony/golang_workspace/bin"
GOCACHE="/Users/anthony/Library/Caches/go-build"
GOENV="/Users/anthony/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/anthony/golang_workspace/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/anthony/golang_workspace"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/anthony/.../go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6t/v80c8sfs5zqf38b2yhzq592h0000gn/T/go-build3004086577=/tmp/go-build -gno-record-gcc-switches -fno-common"

 godepgraph -horizontal  -s -novendor ./internal/config | dot -Tpng -o godepgraph.png

$ ls -l vendor/github.com/            
total 0
drwxr-xr-x   3 anthony  staff   96 Aug 15 12:17 BurntSushi
...
drwxr-xr-x   5 anthony  staff  160 Aug 15 12:17 go-playground
...

Expected Behaviour

No vendored packages in the graph.

Hi! I encountered an error:

~/work/my_project$ godepgraph -novendor -s -p github.com,google.golang.org,gopkg.in {gitlab_repo/project/subproject/package_name}

2021/03/25 00:13:56 failed to import {gitlab_repo/project/subproject/package_name} (imported at level 1 by ):
module {gitlab_repo/project/subproject}: git ls-remote -q origin in /home/user/go/pkg/mod/cache/vcs/{COMMIT_HASH_HERE}: exit status 128:
remote: 
remote: ========================================================================
remote: 
remote: The project you were looking for could not be found.
remote: 
remote: ========================================================================
remote: 
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists

Environment: go version go1.15.7 linux/amd64 Linux 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Package go.mod contains header module gitlab_repo/project/subproject/package_name

I assume that this is due to gitlab has subprojects and thus incompatible path to module. How to resolve such behavior? Thanks

If you have a package in a directory named somepackage and import it from your main package using

import (
    "./somepackage"
)

and then you have another package named otherpackage and import somepackage in it using

import(
    "../somepackage"
)

It will be picked up as two separate packages, one being ./somepackage and the other being ../somepackage.

Potential Fix

For local packages like this, would it work better to resolve the absolute paths of relative packages. If two are the same, ommit one. Afterwards, you can update their names again by generating the relative path to the package from the main package. Does this make sense?

Why this change?

With a very simple repository for demonstration:

git clone https://github.com/leventeliu/godepgraph-demo.git
cd godepgraph-demo

Initially, when I was trying to get dep-graph inside a go module (given filter -o <prefix>) with a relative import path syntax, godepgraph gave an empty result:

$ godepgraph -o github.com/leventeliu ./cmd/nop
digraph godep {
splines=ortho
nodesep=0.4
ranksep=0.8
node [shape="box",style="rounded,filled"]
edge [arrowsize="0.5"]
}

After some code reading, I found the correct way to do it cloud be:

$ godepgraph -o .,github.com/leventeliu ./cmd/nop
digraph godep {
splines=ortho
nodesep=0.4
ranksep=0.8
node [shape="box",style="rounded,filled"]
edge [arrowsize="0.5"]
"./cmd/nop" [label="./cmd/nop" color="paleturquoise" URL="https://godoc.org/./cmd/nop" target="_blank"];
"./cmd/nop" -> "github.com/leventeliu/godepgraph-demo/a";
"./cmd/nop" -> "github.com/leventeliu/godepgraph-demo/b";
"github.com/leventeliu/godepgraph-demo/a" [label="github.com/leventeliu/godepgraph-demo/a" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/a" target="_blank"];
"github.com/leventeliu/godepgraph-demo/b" [label="github.com/leventeliu/godepgraph-demo/b" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/b" target="_blank"];
}

But it's weird, isn't it? The problem here is that the relative path ./cmd/nop could (and should) be resolved as a full package path github.com/leventeliu/godepgraph-demo/cmd/nop, which will not be ignored by the filter -o github.com/leventeliu.

And after I tried the list command:

$ go list ./cmd/nop
github.com/leventeliu/godepgraph-demo/cmd/nop

I thought this is the proper way to solve the problem.

List command is implemented by an internal package, which will be tricky to call directly. Alternatively, I use an os/exec.Command to call go list and pass the parent environment to the command (any better idea?)

Now it works well:

$ godepgraph -o github.com/leventeliu ./cmd/nop
digraph godep {
splines=ortho
nodesep=0.4
ranksep=0.8
node [shape="box",style="rounded,filled"]
edge [arrowsize="0.5"]
"github.com/leventeliu/godepgraph-demo/a" [label="github.com/leventeliu/godepgraph-demo/a" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/a" target="_blank"];
"github.com/leventeliu/godepgraph-demo/b" [label="github.com/leventeliu/godepgraph-demo/b" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/b" target="_blank"];
"github.com/leventeliu/godepgraph-demo/cmd/nop" [label="github.com/leventeliu/godepgraph-demo/cmd/nop" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/cmd/nop" target="_blank"];
"github.com/leventeliu/godepgraph-demo/cmd/nop" -> "github.com/leventeliu/godepgraph-demo/a";
"github.com/leventeliu/godepgraph-demo/cmd/nop" -> "github.com/leventeliu/godepgraph-demo/b";
}

This improvement applies to the case when you are working with "GOPATH mode", instead of go module, too.

Also, this implies a special pattern /... will be supported:

$ godepgraph -o github.com/leventeliu ./...
digraph godep {
splines=ortho
nodesep=0.4
ranksep=0.8
node [shape="box",style="rounded,filled"]
edge [arrowsize="0.5"]
"github.com/leventeliu/godepgraph-demo/a" [label="github.com/leventeliu/godepgraph-demo/a" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/a" target="_blank"];
"github.com/leventeliu/godepgraph-demo/b" [label="github.com/leventeliu/godepgraph-demo/b" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/b" target="_blank"];
"github.com/leventeliu/godepgraph-demo/cmd/nop" [label="github.com/leventeliu/godepgraph-demo/cmd/nop" color="paleturquoise" URL="https://godoc.org/github.com/leventeliu/godepgraph-demo/cmd/nop" target="_blank"];
"github.com/leventeliu/godepgraph-demo/cmd/nop" -> "github.com/leventeliu/godepgraph-demo/a";
"github.com/leventeliu/godepgraph-demo/cmd/nop" -> "github.com/leventeliu/godepgraph-demo/b";
}