NuPack– .Net Package Management… and much, much, more
Yeah.. so all the Ruby and Java guys are saying.. Its about time .Net got a package management system. There were a few growing in the open source space, but none have really gained any traction. Nu seemed to be getting going, I saw it earlier on at Pablo’s Fiesta here in Austin at the beginning of the year. I would pull the source down and it seemed to be going, but slowly. It has picked up some traction over the summer. But now that they guys have gotten together with Microsoft to make NuPack, I think we are going to see some interesting things happen in the .Net space. Why is that?
Package management is a thankless job
First, let me say that writing a package management system is like being the guy who cleans out septic tanks… No one wants to do it. But for the greater good of the community it has to be done. Every Alt.Net conference I have been to has had a session about writing a package management system, and everytime we left saying we would do it, and it never got done or hardly past started. A few have stepped up to the plate, but I am so happy to see Microsoft putting a team of people out their to work on this full time on an open source solution. Most open source projects in the .Net space have sparse commit logs. I think you will see how much work has been invested into this solution when you look through the source code on the NuPack project website.
More than package management.
NuPack goes beyond package management and moving bits from a server to your workstation, it adds all the hooks needed to make hooking up new tooling and assemblies inside of Visual Studio a non event. The biggest sell here is that instead of dealing with copying in boilerplate code, or adding nodes to configuration files, the packages can now just do that work. I personally believe the reason Ruby and Rails has had such great velocity and acceleration is because of of the Ruby Gems system. It is the super highway of reusability. The .Net space has just dealt with horrible documentation and even worse XML configuration and it has been killing us. I really think NuPack is a key piece to help change that story. I have worked on two projects when I was at Headspring to try to make it easier to replicate solutions. They were Solution Factory and Flywheel. Both were great ideas conceptually but in the end I found that I did not want to be the guy cleaning out the septic tank. It really took a team of people to pull this off and make it work frictionless(ly) in Visual Studio.
The future is bright
The future of NuPack is bright..This means that the sun has set for Solution Factory, while I am not going to shut the doors on the project, I have reworked the code of Solution Factory and its essence is now contained in a single class and packaged as a NuPack package. I think the dramatic changes I was able to make with Solution Factory are a testament to how much of the problem space of Solution and Library reuse automation the NuPack project has taken on. I can see the remaining pieces of the Solution Factory project being totally subsumed by the NuPack project over time. From my point of view, this is a good thing. I would much rather collaborate on a solution than just being a lone committer.
I will post about Solution Factory and what it can do for projects like FubuMVC and Sharp Architecture. I think when combine with NuPack the project can make it trivial to build your own Opinionated solution template.