Mono Gems

So, this week is a Hack Week at Novell, and we are free to choose what we want to hack on. I had several ideas in mind for this week, but I finally decided to work on something that might be completed in one week, and that will be really useful for the Mono community: a repository for sharing Mono libraries.

Well, the idea is not building the repository itself, but all the needed infrastructure to make it easy to share libraries, that is, something like Ruby Gems. So, I'm going to create a set of tools which will allow searching for libraries, downloading and installing, and referencing them from projects. I'm also going to define a way of publishing libraries, and I'll eventually create a real repository in some server where we can start adding some libraries.

Scope of the Project

So, first of all let's state the scope of this project:

• This is going to be a library packaging and distribution system designed for development only. That is, I'm not trying to compete with existing packaging systems. You'll be able to more or less automatically download libraries from the repository, but when building a package for distribution, the package will have to either include the library binary, or have a dependency on a package that provides it.
  
• Only fully managed libraries will be supported for now. In the future we may add support for libraries which need some C glue code by compiling them after downloading.
• It will allow parallel installation of different versions of the same library.
• It will support dependencies between libraries. So, when a library is requested, all libraries on which it depends will be downloaded/installed. Of course it will only work for libraries in the repository.
  

Architecture

My plan is to use Mono.Addins to implement this infrastructure. It may sound a bit strange to use add-ins for building a library management system, but if you think a bit about it you'll see that it makes perfect sense:

• A library can be seen as an extension to the system. There will be an extension point where new libraries will be registered. An 'add-in' will be able to register one or several libraries.
• Mono.Addins already provides a system for publishing, downloading and installing add-ins, including support for dependency check. We can share the same file formats and package management tools.
  
• Such add-ins might include not only libraries, but also Monodoc documentation, support tools or other extensions. For example, we could publish a library which implements a Chart widget, and we might include a chart designer to be integrated in Stetic.
  

Different ways of sharing a library

There will be three different types of library packages:

• Binary package: it will include the library compiled in an assembly. Projects will directly reference this library. At deploy time, the library will be copied together with the application using it.
• Binary package with GAC install. Same as previous, but the library will be installed in the GAC. To run the project it won't be necessary to copy the library to the project directory (since it will be loaded from the GAC). At deploy time, the developer will be able to choose between packaging the library together with the application, or not packaging it and generating a package dependency instead (of course this last option only makes sense if a package providing the library is available).
• Source package: I'm still unsure about this type of package. My idea is that it may be useful to be able to share some classes which are very common, but for which it is not worth to create a .DLL because they are too small. So projects would just include the source files in the project. However, it may also make sense to include the source files in binary packages, even if it's only for debugging purposes. Also, given the multi-language nature of .NET, source-only packages would too limited, since they would be useful only for projects using the same language.
  

Integration in MonoDevelop

My idea is to provide something like the add-in manager, but specialized to installing library packages. After installing a library package, all assemblies it provides would be shown in the references dialog. After adding an assembly reference to a project, if the assembly belongs to a package installed in the GAC, the user will be able to set or reset the 'local copy' flag.

I'm still not sure if it would make sense to add an "Include Library as Source" command, which would include the source files of the library to the project.

Integration in Visual Studio

Why not? it would dramatically increase the number of potential libraries and users. Any volunteer?

Command Line Tools

There will be a command line tool for managing library packages, and for querying information about libraries. This should be some kind of replacement of pkg-config for Mono. It will be able to check if a library package is installed, and which assemblies does it provide.

Configuration scripts might be able to use this tool to automatically download packages not installed in the system.

Library Repository

I don't plan to implement any server-side logic or service for publishing or browsing libraries. An on-line library repository will be a set of package files in a directory and an index file. We can easily generate a set of static html files for the repository and for each package, so that people can browse it and Google can index it.

Looking for a Name!

"Ruby Gems" sounds really cool. Any idea about how all this infrastructure could be named in Mono?

Other more general comments and suggestions are also welcome :)