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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe