Well, that's true. I guess what I'm really objecting to in Claus's message is the implication that we should always use a Haskell Installation Manager, even on systems with good built-in package management.
what was implied was that haskell installation manager (HIM) and native package managers (NPM) (where they exist) should collaborate, so that NPMs know how to extract dependencies from haskell packages, and HIM knows how to extract dependencies (haskell or otherwise) from NPMs. for the NPM-calls-HIM direction, that could be dynamically or, as in current practice, in a separate phase converting HIM to NPM packages. for the HIM-calls-NPM direction, that would simply present a haskell view on the native software (ie, cabal install/list/.. negotiating with NPM). whereas, currently, if i understand correctly, systems with NPM will have many haskell packages under NPM control and some haskell packages under HIM control and some haskell packages under no control whatsoever (eg, installing tools or compilers leaves no record, necessitating use of autoconf & co). i'm not saying "reimplement and ignore NPMs", i'm saying "NPMs and HIM should collaborate". if anything, that would reduce the number of exceptions where haskell packages are installed without the NPM knowing about them. and i'd like to see fewer cases where HIM forgets about what it or NPM have installed. so, on systems with NPM, users have a choice of interface, but nothing bad will happen no matter whether they choose NPM directly or HIM as an interface to it. and haskell book and tutorial authors only need to explain HIM, and its commands will just work - independent of the variant or lack of NPM on the reader's system. is that still objectionable?-) claus ps. it is a lot like using fmap, no matter what the Functor is, or using something like System.Process, no matter whether or not the OS supports that easily.
Yes, I agree we need good support for managing packages for the other scenarios: no system package manager, home-directory installs, no pre-prepared system package. I just don't want whatever provision we make for these cases to replace the system package manager for global package installs on systems where that is well supported.
Indeed. I wholly agree.
Duncan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe