Re: cabal and platform-independent haskell installation management (again) (Re: [Haskell-cafe] Re: Ubuntu and ghc)
Claus Reinke [EMAIL PROTECTED] writes: 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. Exactly. Integrating Cabal packages into the system package manager is still non-trivial, and a package maintainer is necessary for this to work. Which is why it's rather utopian to hope that all of Hackage can be found in even the most widely used distributions, since many of those are way to narrow in scope for somebody to take on the work of providing package management. I bet some aren't even maintained, and possibly don't work with current GHC or Cabal. But I digress. - 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. There is an important difference between Hackage and, say, Ubuntu, and that is that the latter does releases. If I use a particular Ubuntu version, I get a particular GHC version, and a particular version of some dozens of libraries and applications. They are all compiled with that GHC version, tested, and can to a reasonable degree, be expected to work together. Sometimes they don't, but the good news is that a zillion other users are in the same boat (well, even for Haskell, it's probably dozens, at least), and chances are the bug will be fixed. If I upgrade to the next version of Ubuntu, I can reasonably expect all packages to be updated to current versions, and some to be replaced. In contrast, for my packages on Hackage, I'm reasonably certain it worked on my particular system at the time I uploaded it. And dependencies are none too specific - the package might work with different versions than I compiled with or not. I think for Cabal to provide the convenience currently afforded by system package managers, you'd need to do Hackage-wide releases, and test everything together. This is a lot of work, but not impossible, it's what Gnome and KDE does, for instance. It would probably make things easier for system package maintainers, too. Alternatives, like pessimistic dependencies: only exact versions in cabal files, will probably make you end up with installing every version of every package, and still suffer dependency hell. Exhaustive testing of all version combinations, which will require a lot of computational resources, even if it could be done automatically. -- I generally install most libraries from the distribution's repository, and let the system worry about updates etc. I think it's also an advantage if my programs avoid depending on stuff that's not in the repo, since it's likely to be is less widely used and maintained. I install manually the stuff I need the distribution doesn't provide, and also when I want to look at the code, or just have the latest and greatest. I tend to get the darcs version, rather than the Hackage one, though. The downside is that I need to reinstall these when I do a system upgrade, but it's rare enough that it doesn't bother me much, and chances are that more libraries are provided with my distribution for every release, so a cleanup is probably a good idea anyway. Anyway, this works pretty well for me - if I'm living on an illusion, it's at least a good one. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
cabal and platform-independent haskell installation management (again) (Re: [Haskell-cafe] Re: Ubuntu and ghc)
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: -
Re: cabal and platform-independent haskell installation management (again) (Re: [Haskell-cafe] Re: Ubuntu and ghc)
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
Re: cabal and platform-independent haskell installation management (again) (Re: [Haskell-cafe] Re: Ubuntu and ghc)
On Wed, Jun 4, 2008 at 10:14 AM, Claus Reinke [EMAIL PROTECTED] wrote: - 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. It's sufficient to worry about the problem at hand. Everything you've mentioned can be done incrementally once the depsolver is happy. After that it's quite likely that the set of people who care about lifetimes and integration stuff will intersect with the people who want to work on said stuff. -- Darrin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
