Re: RFC: include a cabal-install executable in future GHC releases
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 librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
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 gan...@earth.liwrote: 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 librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Agreed. That's exactly what we have Platform for: to give the user an integrated set of tools. My vote is to have only the things that are really necessary being included in the ghc distribution. Отправлено с iPad 21 янв. 2014 г., в 23:22, Ganesh Sittampalam gan...@earth.li написал(а): 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 librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ 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
Re: RFC: include a cabal-install executable in future GHC releases
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 gan...@earth.li mailto:gan...@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 librar...@haskell.org mailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org mailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
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 gan...@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 gan...@earth.li mailto:gan...@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 librar...@haskell.org mailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org mailto:librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
