Re: RFC: include a cabal-install executable in future GHC releases

ANYWAYS :) the point is: there is a nonzero population of haskell folks who want to use ghc + cabal-install on a machine where they may not have admin / package manager powers, AND it requires some amount of cabal-install familiarity (or asking around) to find out about the ./boot-strap script that cabal comes with. (I've definitely had 1-2 incidents where on a new server i did the bootstrap process by hand before i found out about that script) at the very very least, the directions for boostrap cabal-install should be more discoverable On Wed, Jan 22, 2014 at 10:45 AM, Johan Tibell wrote:

On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel wrote:

...

On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:

...

I feel this blurs the roles of GHC and the Platform.

IMO, that's a weak argument, as the roles are already blurred:

GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead. Moreover, GHC ships with a set of base libraries (which, and thus effectively GHC forces 20 or so packages (fixed to specific package versions) into the HP and takes away authority from the HP release process. But now the difficult to explain thing is that GHC also bundles the library part of CABAL but deliberately leaves out CABAL's frontend tool `cabal-install` only to justify the existence of the HP a bit more? :-)

Cabal is part of GHC's build process and GHC uses data types from Cabal. That's why it's there. It's not because we want Cabal to be included (just like we don't want to ship those libs.) These are technical limitations.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries