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

[Carter Schonwald]

Ok,

so either

a) provide a ghc + cabal-install binary included (heck, its easy to update
to a cabal install anyways, and the ~/.cabal/bin path will be before
wherever the ghc pkgs are installed anyways. The same argument could be
made for packaging happy and alex with ghc too! ). After all, i already
have a happy / alex from cabal-installing them from earlier, why should ghc
install it again? :p



b) either way, perhaps the cabal-install devs/maintainers should
standardize making some binaries available




On Tue, Jan 21, 2014 at 3:44 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:

> If you can't find any better options, I can try to run a buildbot on a
> laptop that's probably mostly online.
>
>
> On 21/01/2014 19:32, Johan Tibell wrote:
> > We could offer OS X and Linux binaries in addition to the Windows
> > binaries already downloaded on the cabal home page
> > (http://www.haskell.org/cabal/) if someone could commit to building
> them.
> >
> > Aside: Right now building the Windows binaries is a very ad-hoc process
> > (I email Mikhail who has a Windows machine and ask him to build one).
> > I'm not very keen to make the process even slower, given that that will
> > mean I will make fewer cabal releases. Ideally the binaries could be
> > produced on a build bot. The very least we should have the Makefile in
> > the cabal repo being able to create the binary in a reproducible manner.
> >
> > -- Johan
> >
> >
> >
> > On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam <ganesh at earth.li
> > <mailto:ganesh at earth.li>> wrote:
> >
> >     I feel this blurs the roles of GHC and the Platform.
> >
> >     Can't the cabal-install that comes with the Platform can be used
> with a
> >     later GHC installation? If that's correct, then the only use case
> that
> >     this proposal covers is someone who wants to use a bleeding edge GHC
> and
> >     no other version on a new machine. A separate binary distribution of
> >     cabal-install should be more than adequate for that and it avoids
> >     coupling GHC to other things.
> >
> >     So a weak -1.
> >
> >
> >     On 20/01/2014 00:02, Carter Schonwald 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
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Libraries mailing list
> >     > Libraries at haskell.org <mailto:Libraries at haskell.org>
> >     > http://www.haskell.org/mailman/listinfo/libraries
> >     >
> >
> >     _______________________________________________
> >     Libraries mailing list
> >     Libraries at haskell.org <mailto:Libraries at haskell.org>
> >     http://www.haskell.org/mailman/listinfo/libraries
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140121/feb32a36/attachment.html>