Our friends from Japan have a beautiful event called “F# Advent Calendar“. Every day from December 1 to December 31, one awesome volunteer publish a new post about F#. What an amazing way to celebrate Christmas, isn’t it?
Lets support this initiative and do an English version of the calendar. Two blog posts per day is better than one, isn’t it? We need 31 volunteers, who are ready to prepare a post about F# and publish it on specified date.
Rules
Rules are very simple:
Choose F# related topic for your blog post and send it to me on Twitter or leave a comment to this post.
Prepare a blog post in English (about F# or using F#)
Publish your post on specified date (according to the calendar)
Post link to your post on Twitter with hashtags #fsharp and #FsAdvent.
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.
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.
Packages that are in scope of analysis (green on the graphs)
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.
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!FSharp.Compiler.Service is already deeply incorporated in tooling!Too many different Fsharp.Core packages on NuGet adopted by different tools.FSharpx is still alive! 😉Roslyn ohhhh Roslyn
Thank you for being with us during these two years, reading the news and participating in community life. Thank you to everyone who contributed to F# Community Projects and Visual F#. I hope you will stay with us and I will be glad to see new faces next year.
Paket is an alternative alternative dependency manager that replace nuget.exe in your repository and enables precise control over your dependencies. Features:
Referencing files directly from GitHub repositories.
