NuGet dependency visualizer with F# and Graphviz

Script for this article is available as public Gist.

For a long time I was interested in what is going on on NuGet. I think that NuGet UI does not provide one important piece of information – which packages depend on current packages. This information is very useful for package authors and also can help a user to find packages that provide more sophisticated implementation.

Other interesting thing is to see the big picture and answer some global questions:

  • What is inside the technology I use? What is the dependency of packages that I use? What are dependencies of dependencies and so on.
  • What is built on top of packages that I maintain? What beautiful applications of my ideas other can find? What is the cost of releasing a broken package? Who can be harmed?

I believe that there are a lot of other answers we can find from the high view.

Some time ago I have found that NuGet team provides NuGet.Core package that has all  API required to communicate with NuGet. The API is not really fast if you are going to download information about all versions of all NuGet packages 😉 But NuGet team is working on a new v3 API that is going to be much faster than current v2. For current research I have downloaded info about all packages and all their versions to my FSI session to be able to run different types of analysis and create visualizations without further communication with NuGet. This operation is slow enough: it took about 1 hour last time when I run it, but it really depends on NuGet workload and your internet connection.

The second thing is visualization of the result, here I want to say thank you to Scott Wlaschin for his great script type-dependency-graph.fsx (that was built for ‘Cycles and modularity in the wild‘ analysis). I took his GraphViz module and slightly modified it to allow colorful graphs printing. To use it you need to download GraphViz from the official site.

That is all tooling that we need. So we are ready to describe a structure of an analysis – script extracts 3 subsets of NuGet packages and visualizes them in different colors with all dependencies.

  1. Packages that are in scope of analysis (green on the graphs)
  2. Packages that we depend on (grey on the graph) – Package is in the set 2 if exists a dependency path from any package from Set 1 to this package.
  3. Packages that depend on us (blue on the graph) – Package is in the set 3 if exists a dependency path from this package to any package from Set 1.

NOTE: In this analysis I ignored package version and considered only latest package version and dependencies of latest version. If you need more accurate analysis you should adjust script a bit.

Running this script I did some interesting observations:

FsPickler is already highly used by other packages!
FsPickler is already highly used by other packages!
FSharp.Compiler.Service is already deeply incorporated in tooling!
FSharp.Compiler.Service is already deeply incorporated in tooling!
Too many different Fsharp.Core packages of NuGet adopted by different tools.
Too many different Fsharp.Core packages on NuGet adopted by different tools.
FSharpx is still alive! ;)
FSharpx is still alive! 😉
Roslyn.dot
Roslyn ohhhh Roslyn

 

F# Ecosystem is HUGE! (see full svg version here, surry bug without FunScipt ;))
F# Ecosystem is HUGE! (see full svg version here, sorry but without FunScipt ;))

I hope that you’ll also find this script useful and discover something interesting on NuGet.