+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@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@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users