cabal and platform-independent haskell installation management (again) (Re: [Haskell-cafe] Re: Ubuntu and ghc)

[Duncan Coutts]

On Wed, 2008-06-04 at 15:14 +0100, Claus Reinke wrote:
> > I think that's fundamentally the wrong approach.  We shouldn't have to 
> > build a "Haskell installation manager".  Would you also want installation 
> > managers for Perl, Python, Ruby, C, C++, etc. each with their own different 
> > user interfaces and feature sets?  I think not - you want a single package 
> > manager for the whole system from which you can install/uninstall libraries 
> > for any language.
> > 
> > This is something that Windows gets completely wrong.  Why do I have twelve 
> > icons in my status bar all representing little programs that are running in 
> > the background checking for updates to their own bits of software?  Why on 
> > earth do I have a Printer Driver Update Manager?  And I'd be wondering the 
> > same thing about a "Haskell installation manager": installation and 
> > dependencies are not something specific to Haskell.
> 
> why then do we have ghc-pkg, or cabal? surely the native package
> managers should handle all that?
> 
> there are (at least) two dimensions of uniformity: across different
> kind of software on a single kind of system, and with a single kind 
> of software across different kinds of system. platform-specific
> package managers hide the software-specific notions of package
> dependency maintainence, haskell-specific package managers
> hide the platform-specific notions of package dependency 
> maintainence. 
> 
> there is no need for platform- and haskell-specific tools to be 
> entirely separate or in conflict with each other: where both exist, 
> one can be a view on the other (if you are on linux-of-the-day, 
> you can use its package manage, independent of whether your
> packages are haskell or lisp; and if you are using haskell, you
> should be able to use its package manager, independent of
> whether you are on unix-variant-of-today or on 
> unix-variant-of-yesterday).
> 
> there seems to be a lot of confusion here, some of us not 
> understanding the issues because we happen to be using
> systems where "everything just works", others among us
> not understanding the issues because we happen to be
> using systems where "such things would never work anyway",
> and yet others insisting on "i'll do it my way, so i know what
> works" (and then, of course, there are those who are
> actively working on improving the situation who will see
> my criticism as constructive, i hope!-).
> 
> 1. there are no systems where "packages just work"!
>     there are systems where a few people ensure that
>     many people can live in such an illusion, though.

Yes indeed! :-)

> 2. systems with native package manager software still
>     need help from haskell-specific toolchains (unless
>     you want the human package managers on those
>     systems to code all haskell-specific dependencies
>     by hand).

Yes. As an illustration: gentoo has an "haskell-cabal.eclass" that
interfaces between ebuilds and cabal as the build manager and there is a
tool to generate ebuilds that use the haskell-cabal.eclass from .cabal
descriptions (so we get correct deps automatically).

> 3. systems without native package managers (or perhaps
>     i should say: systems on which users with unix background
>     traditionally avoid getting acquainted with the details and 
>     usage of whatever might pass as installation management 
>     on those systems) are still in *very* wide-spread use, 
>     and if haskell users on those systems are left out in the
>     rain, haskell developers will not be able to support those
>     systems. this limits the user and application base of haskell
>     on those systems, making haskell less relevant than it could be.

Eg Windows, OSX, Solaris.

> 4. haskell enables programming at a very high level of 
>     abstraction, with fairly good support for mostly platform
>     independent code. but that code needs to be installed, 
>     and integrated with dependencies and dependents, and 
>     the integrated haskell installations needs to be maintained.
>     and that should "just work", even if the developer is on
>     (1;2) and the user is on (3), or vice versa, or if developers
>     and users are on different flavours of (1;2) or (3).
> 
> with these clarifications out of the way, my interpretation 
> of cabal was that it set out to provide two things
> 
> (A) a uniform platform-independent interface to such a 
>     haskell package installation manager.
> (B) a uniform platform-independent toolchain to support
>     such a haskell package installation manager.

I guess so.

> on systems in the (1;2) class, human package managers 
> would use (B) to integrate haskell packages into the native
> package management software, so users might never even
> encounter cabal.

As in my example with the gentoo haskell packages above.

>  even so, (A) might offer a haskell-specific
> view on the general platform package management (when 
> you want to see the haskell gui libs rather than all gui libs).
> 
> on systems in the (3) class, users and developers would
> interface with (A/B) directly, for lack of a better alternative.
> 
> and developers/users in the (4) class would simply use
> (A/B), without having to check whether they are "real"
> or just a view on the platform-specific software. it is this
> cross platform view of software development that i'm
> most interested in (i'm one of those who use bash, vim,
> opera, and haskell, no matter whether i'm on windows,
> solaris, or whatever, and the cross-platform availability
> of those tools has saved me many a headache;-).
> 
> returning to my earlier message, it seems that my 
> concerns were mainly these:
> 
> - it isn't sufficient to worry about installation management,
>     one has to worry about integration, lifetime and uninstall
>     management as well. in short, maintain the dependency
>     graphs over any of "install"/"upgrade"/"uninstall".

For users in (1;2) class we would expect the native package manager to
do this.

> - for this to work, cabal needs to maintain not only
>     libraries as packages, but tools and compilers as
>     well. without this, some dependencies are not
>     recorded (this haddock depends on that ghc; to
>     build this package i need that tool; that tool was 
>     built with this ghc version, from those sources, etc). 
>     
>     and if the dependencies are not even recorded, they 
>     are likely to be broken if one does install/upgrade or
>     uninstall any haskell software, be it library, tool, or
>     compiler.

Right. Currently cabal-install in its roll as a secondary package
manager is very weak on that front. It does not record anything about
what it installs. There's clearly plenty of work to be done there.

> ps. i'd cc to libraries or cabal, but i don't know which
>     would be most appropriate (perhaps someone could
>     point readers there to this thread if that sounds relevant?).

You can cc both.

Duncan