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

[Gábor Lehel]

+1 to this proposal. The benefits are obvious and practical: when
installing a new GHC, it will save users the tedium of having to figure out
how to build a cabal-install and then do so before they can install the
packages they actually want. The drawbacks are indefinite and amorphous:
the download is a little bit larger. So what? It further blurs the line
between GHC and the Platform. Who does this harm? People who already have a
cabal-install will now have a second one. What discomfort will this cause
them?


On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey everyone,
>
> I'd like to propose that GHC releases 7.8.1 onwards include a
> cabal-install (aka cabal) executable, but not include the library deps of
> cabal-install that aren't already distributed with ghc.(unless ghc should
> have those deps baked in, which theres very very good reasons not to do.).
>
> currently if someone wants just a basic haskell install of the freshest
> ghc  they have to install a ghc bindist, then do a boostrap build of
> cabal-install by hand (if they want to actually get anything done :) ).
>
> This is not a human friendly situation for folks who are new to haskell
> tooling, but want to try out haskell dev on a server style vm or the like!
>
> point being: It'd be great for haskell usability (and egads amounts of
> config time, even by seasoned users) the ghc bindists / installers included
> a cabal-install binary
>
> thoughts?
> -Carter
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140125/8561a18f/attachment.html>