cabal and platform-independent haskell installation management
(again) (Re: [Haskell-cafe] Re: Ubuntu and ghc)
duncan.coutts at worc.ox.ac.uk
Wed Jun 4 10:43:48 EDT 2008
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
> 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
> 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
> - 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
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.
More information about the Haskell-Cafe