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