The Horn Package Management System

By way of starting off my newly birthed blog, I want to self promote the open source project horn that the members of the scotalt.net community have commenced work on.  The goal of the project was to firstly promote the tenets we believe are important for writing robust and maintainable software.

These tenets are in no particular order:

• TDD with a bit of a BDD splash to specify the code pickings
• Inversion Of Control for dependency resolution
• High level modules should not depend on low level components, both should depend upon abstractions.
• Continuous integration for feedback on every source control check in

After the usual exchange of everyone self promoting their own personal ideas somebody came up with the extremely bright idea of creating a package management system along the lines of maven that can take the pain away from building .net source code packages that usually come from open source projects. Rather upsettingly this idea did not stem from me.

Let me paint a pain scenario that I am currently experiencing. I use a stack that is probably quite similar to a lot of developers who follow some of the ALT.NET ideologies. That stack consists of Rhino, Castle, NHibernate, MVCContrib etc.  One of the ill affects of such a stack is the constant treadmill like upgrading of components where I can quite literally lose a day downloading the source, fiddling with the Nant scripts in order to get the damn thing to build.  For a man who possesses an infamous bad temper this can be quite disturbing for anybody in close proximity of __the__mad__man__ wrestling with the aforementioned components. The end result is that I quite literally loathe this never ending routine of upgrading.

The proposed scheme of horn is to take control of the building of source code packages from a scm repository and resolving any dependency management for you.

Unsuprisingly .NET is possibly the only platform without a recognised build system. Being a plagiaristic brute, the smart and only option was to base horn on an existing package manager.

This clearly led to the accustomed trawling through reams of scant open source documentation to find a good candidate for replication. I first read up on Maven which was instantly off putting because of the heavy dependency xml mark up used to define the build configuration. Then Craig Nicol suggested the portage system which intuitively felt like the ideal choice.  At the heart of portage is the metaphor of the Portage Tree.  This curious tree is simply a directory structure that categorises and constrains the package definitions. The package tree can be thought of as a database of components and dependencies. What is really interesting is how the tree is used to check such things as circular referencing. Some extra reading on the portage tree can be found here.

Scattered around the portage tree structure are build file definitions written in bash called ebuilds that contain metadata about the package and build instructions.

With the best template system in place we started work on defining a set of tasks in a expressive BDD syntax. The first iteration goal was quite simply to download horn from subversion, build the source and place the output of the build in a designated output directory. Our first draft of specifications can be found here.

With this in place we were up and running. We had a quick heads up over skype and got some basic architecture in place.

The first task was to define a syntax for defining both the build metadata and build instructions a.k.a. horn’s implementation of portage’s ebuild. With xml being desperately out of vogue we opted for a DSL syntax which would be written in boo.

If any of this interests you then please join the horn user group for updates or check out the source here.