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

[Claus Reinke]

> 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.

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).

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.

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.

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. 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 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.

i hope this clarifies things?-)
claus

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?).