Once everything is installed, the following command: 

$ godepgraph github.com/kisielk/godepgraph | dot -Tpng -o godepgraph.png

Will produce the following pretty picture for you:

As you can see, the dependency graph for godepgraph is nice and flat, and only relies on packages from the standard library (the green circles).

Let's try something a little more complicated: let's generate the dependency graph for the code we are going to use in the second part of this book:

$ godepgraph github.com/PacktPublishing/Hands-On-Dependency-Injection-in-Go/ch04/acme/ | dot -Tpng -o acme-graph-v1.png

This gives us an incredibly complicated graph that will never fit on the page. Please take a look at ch03/04_visualizing_dependencies/acme-graph-v1.png if you want to see just how complicated it is. Don't worry too much about trying to make out the details; it's not in a super useful form right now.

The first thing we can do to fix this is remove the standard library imports (which have the -s flag), as shown in the following code. We can assume that using the standard library is acceptable, and is not something we need to turn into an abstraction or use DI on:

$ godepgraph -s github.com/PacktPublishing/Hands-On-Dependency-Injection-in-Go/ch04/acme/ | dot -Tpng -o acme-graph-v2.png

We could use this graph, but it's still too complicated for me. Assuming we don't recklessly adopt external dependencies, we can treat them like the standard library and hide them from the graph (with the -o flag), as shown in the following code:

$ godepgraph -s -o github.com/PacktPublishing/Hands-On-Dependency-Injection-in-Go/ch04/acme/ github.com/PacktPublishing/Hands-On-Dependency-Injection-in-Go/ch04/acme/ | dot -Tpng -o acme-graph-v3.png

This gives us the following:

With all of the external packages removed, we can see how our packages relate and depend on each other.