[Haskell-cafe] Library Process (was Building "production stable" software in Haskell)

[Sven Panne]

On Tuesday 18 September 2007 09:44, Dominic Steinitz wrote:
> This discussion has sparked a question in my mind:
>
> What is the process for the inclusion of modules / packages in ghc, hugs
> and other compilers & interpreters?

Personal interest of the people working on GHC et. al. ;-)

> I thought the master plan was that less would come with the compiler /
> interpreter and the user would install packages using cabal. [...]

Although this statement might be a bit heretical on this list, I'll have to 
repeat myself again that Cabal, cabal-install, cabal-whatever will *never* be 
the right tool for the end user to install Haskell packages on platforms with 
their own packaging systems like RPM (the same holds for other systems, I 
just use RPM as an example here). This packaging system, and nothing else, 
will write into my /usr, otherwise chaos and versioning hell will threaten 
the system integrity. Cabal is a very fine tool to be used from RPM .spec 
files and to develop below one's own home directory, but it is not the tool 
of choice for the final installation. There are various reasons for this:

   * Imagine you want to find out to which package in which version a given 
file belongs. Impossible, if RPM is bypassed.

   * RPM offers functionality to verify the integrity of the installed SW, it 
can tell me which files are documentation, which ones are configuration 
files, etc. All this meta information has to be in a single system.

   * YaST, yum, etc. already have the notion of repositories, trust (via 
standard cryptographic methods) and resolving transitive dependencies, so we 
would re-implement things which are already there, well maintained and 
well-known to end users.

   * Imagine every language would force their end users to use specific tools 
for installation, this would be ridiculous. Personally I don't care at all 
about the details how Perl modules, some PHP/Python/... libraries etc. are 
installed on my system. This knowledge belongs to the packager who builds a 
nice RPM, mentioning all dependencies, so my favourite RPM tool can 
transitively resolve, download and install everything, offering a nice GUI if 
I like. No need to remember how to do this for Perl/PHP/Python/etc.

Regarding the pros and cons of small, separate packages: In general I agree 
that this is the right direction, and this is what other languages do as 
well. There are e.g. tons of Perl/PHP/Python/Ruby RPMs available for my 
system, each offering a specific library, while the RPMs containing the 
interpreters/compilers are rather small. But: IMHO we are not there yet, 
because we still have to remove quite a few rough edges until we can smoothly 
offer e.g. an RPM repository with lots of small library RPMs (Cabal 
versionitis, updating the Haddock documentation index, etc.). Therefore, I'll 
continue to offer only "Sumo-style" RPMs for GHC + boot-libs + extra-libs for 
now, but I hope I can change this in the future.

Another point: Although this is hard to believe nowadays, ;-) people are not 
always online, so "simply" installing what is missing might not always be an 
option. "Great, I'd really need the foobar-2.1 package now, but I'm currently 
10000 feet above the Atlantic ocean..." The right way to tackle this problem 
is using meta packages, basically referencing lots of bundled small packages. 
RPM offers such a feature, and I guess other systems, too. On a laptop, such 
a meta package leading to the installation of tons of libraries is the right 
approach, on a fixed workstation the story might be different.

Cheers,
   S.