Today I learned about the Hornget project which is lead by Paul Cowan. Hornget attempts to solve the elusive “package manager for .NET” problem by creating a packager system for open source .NET projects.
An interesting choice the Horn project team made was to keep the repository (not the design pattern, the actual place where the project meta data is stored) building from source and eschew binary packages altogether. Paul actually makes a very compelling case for this choice in his presentation at DSL DevCon.
While I agree that having the build from source option available is a good idea, I don’t think it should be the default option. Or at least, I think that a binary install option of equal weight should be available.
The Horn dependency and package system is based, at least in part, on the Gentoo Linux Portage manager. When Gentoo first showed up on the linux scene I started using it as my linux desktop and server of choice. The Portage system has awesome dependency resolution and listed the latest and greatest versions of packages like KDE, Gnome, and all the STABLE versions my favorite applications. I highlight stable because that’s what I like to use – the stable version – especially for important or production situations.
The thing I hated about Gentoo was waiting for packages and their dependencies to compile. Most small applications built fast. Most large ones, like x-org, Gnome, and KDE didn’t. The process usually went something like this: Start build, go to bed, wake up the next day and hope there were no build errors.
Now to be fair, there are no packages in Horn that will take all night to build. However…
This is what happened when I tried to install log4net from source. The build failed. This happens more often than people may think. And it’s why I think a “install from binary” option is needed.
Pauls argument for building from source via his presentation goes something like this:
- All developers like to use the bleedingest edgiest version of a software package so we all download from trunk and compile.
- Because of this, we have dependency issues during builds because the source from a dependent package may be out of date. Thus, that package also needs to have the freshest source pulled and built. (ie, dependency checking and resolution)
I agree that these are issues. But only when building from source. The question then becomes, do most developers use the latest trunk builds of open source projects like Nhibernate, Castle Windsor, and MVCContrib?
Having spent a lot of time on both the MSDN and ALT.NET side of the developer camps, I’m comfortable saying that a lot of people don’t want to build from source. They don’t want to use the latest bleeding edge version. They just need the package to work stably and reliably. Horn pulls the source from the repository itself where the project is hosted. (so far only svn is supported but git is on the way) There is no gateway to be sure packages are stable and feature complete. Just because something builds doesn’t mean it’s ready to be tagged as the next version.
This raises some more questions which I haven’t been able to answer myself yet: Who decides what packages are inside of Horn right now? Presumably Paul and his team are playing things a little close to the vest right now, adding prominent open source projects to their repository, and making sure they build correctly. And that’s the right thing to do. But who decides when the next version of a package is ready to be included in the repository? Does the original developer team have a say? If they commit each night and the Horn build “checker” doesn’t fail does this mean that a new build of a project is available each day? In the future, will I be able to add my own open source project to the Horn repository? Will I have any control over how often it’s versioned?
I’ve actually been thinking a lot about this problem over the last couple of months and I think I have a solution which I’ll detail in a future post.
For now, however, I really do wish the Horn project team well. I’ve already joined the Google Horn Developer Group to follow the goings on and will hopefully be able to inject some opinion about adding binary support.
Give the Horn project a look. It very well could be the future of .NET package management for community and open source projects!
Couldn’t agree more. While I loved Gentoo (because I was the idiot that wanted to squeeze that extra cycle out of my CPU a few years ago) I quickly replaced it with Arc Linux (pacman package manager) and eventually Ubuntu (apt). I don’t care about bleeding edge blah – I’d rather the devs of the packages make sure the shit is stable and ready to be used.
I like the idea of “unstable” or “untested” repositories, or the ability to build from source with a flag option in the package manager, but unless I make a conscious decision to go down that particular pain-path, give me a binary. (Especially in the Windows/.NET world, where dependencies can be handled a lot easier.)
Now if macports would just give me a binary install option…
Hi,
I just do not see how binary support will actually work. I would love to be proved wrong mind you. All OSS works irrelevant of each other. You only have to look at the various versions of the boo libraries that exist in Castle, Rhino and whatever else uses it to see what a mess it is.
It is just not about be bleeding edge. It is about getting a stable build with everything at the same level. If NHibernate releases a stable release of say 2.1 then the only way I can ensure that the castle libraries that I use are going to work against this version of Nhibernate then I need to build from source.
I honestly believe it is the only way.
I reserve the right to be wrong of course!!
Paul,
Thanks for the comment! First I want to make sure you understand that I’m VERY excited for this project. I’ve been designing something similar for months now but came at it from the opposite direction. The one problem I hadn’t yet solved is the one that you DID solve – quite masterfully I’d add – regarding dependencies and compiling large projects with complex build files.
This post was the first of what will probably be a few on the subject. I just learned of the project yesterday so I’m still doing a lot of reading – both on the Horn website and Google group.
Certainly, I’ve got suggestions but I want to make sure I know where I’m coming from first. For example, if I’m going to suggest adding binary support I want to make sure I can site an example that it’s even possible.!
I’d love to share my diagrams with you so perhaps I’ll send you en email offline. I noticed on a recent group post that you’re pretty busy. As well, I wouldn’t dream of suggesting anything unless I was willing to get my hands dirty. Looking forward to helping out!
Cheers and thanks again for the comments!
I really liked the post and I think this is a debate worth having.
I really hope you get involved and we need all the contributors we can get if this initiative is to continue.
This has been an itch I just had to scratch.
I think binary management is prefered but I just cannot see a way of achieving it. Of course this does not mean there is no way :-).
My email is dagda1@scotalt.net.
I look forward to hearing from you.
My email is dagda1@scotalt.net.