that still requires some discovery though! The idea (i'd hope) would be to make the "my first ghc install on a vm" (for experts and new folks both) go from #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make install PREFIX=yah #figure out how to install cabal, eg discover wget and then ./bootstrap # cabal install thingsIwannaTry to # install ghc via some wget and make #cabal install nice things On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < the.dead.shall.rise@gmail.com> wrote:

Hi,

On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald wrote:

...

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

For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. I guess we could do the same for Linux and OS X.

[1] http://www.haskell.org/cabal/download.html

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Hear hear! This would be most welcome. On Mon, Jan 20, 2014 at 2:14 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

that still requires some discovery though! The idea (i'd hope) would be to make the "my first ghc install on a vm" (for experts and new folks both)

go from

#install ghc via whatever mechanism, eg wget, guntar, cd blah ; make install PREFIX=yah #figure out how to install cabal, eg discover wget and then ./bootstrap # cabal install thingsIwannaTry

to # install ghc via some wget and make #cabal install nice things

On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < the.dead.shall.rise@gmail.com> wrote:

...

Hi,

On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald wrote:

...

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

For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. I guess we could do the same for Linux and OS X.

[1] http://www.haskell.org/cabal/download.html

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Roman Cheplyaka-2 wrote

Once you have cabal-install, you can easily update it with cabal install cabal-install

Which will also have to download and build all the dependencies, as they aren't included. Not the end of the world, but a fresh cabal-install would be a nicer user experience. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

Am 20.01.2014 17:55, schrieb Anthony Cowley:

cabal-install works very well, and is key to getting a Haskell development environment up and running. The only downside is if there is much call for minimal GHC binary distributions: If we would need to provide multiple downloads, that starts to verge into HP territory. So I shall clarify my +1 to say that I always want a cabal-install executable with my GHC, but it would be good to hear from people who really don't want that extra baggage.

For me it would mean duplication. Whenever I install GHC I already have a running cabal-install and I can install a new one, if a new version of cabal-install is released. I think the banner above the GHC download page makes pretty clear, that the binary GHC tarball is not intended for comfort use. Maybe the banner can be extended by a hint, where cabal-install executables can be downloaded.

Agreed. The significant barrier here isn't that cabal-install isn't delivered with GHC (that's HP's job), it's that there isn't a pre-build binary for linux at all, and that the binaries aren't linked to from the GHC download site. -- View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

I don't think that "apt-get install cabal" actually solves the core issue that sparked this thread for several reasons. As someone who had to install GHC from scratch without having sudo access on a (non-Debian) machine, I can testify that the fact that the cabal binary is not part of the GHC distribution, and doesn't have an easily located downloadable binary, has caused me a lot of trouble. AFAIK there isn't any clear description of how someone is supposed to deal with such a situation (unless something has been added in the past year). For example, The problem of handling the distro's package manager (whatever it is) with a language's package is a separate and thorny issue, which I think can't be "perfectly" solved short of unrealistic rewrite-the-world solutions. E.g., what happens if you do apt-get install cabal" and then use cabal to update itself to the newest version? What happens if you then "apt-get upgrade" and there's a newer version than the one apt installed, but it is older than the one you installed manually? etc. I think that "something" need to be done to make it easier to set up GHC + cabal, independently of HP (unless HP becomes the "one true way" to install Haskell, which I doubt is the case). On Wed, Jan 22, 2014 at 11:25 AM, Simon Marlow wrote:

On 21/01/2014 08:42, harry wrote:

...

Agreed. The significant barrier here isn't that cabal-install isn't delivered with GHC (that's HP's job), it's that there isn't a pre-build binary for linux at all, and that the binaries aren't linked to from the GHC download site.

Your Linux distro already provides a cabal-install that will work with the latest GHC, just "apt-get install cabal" or equivalent, then "cabal install cabal-install" to update it if necessary.

Cheers, Simon

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 23 January 2014 15:06, Antoine Latter wrote:

On Wed, Jan 22, 2014 at 4:02 AM, Oren Ben-Kiki wrote

...

For example, The problem of handling the distro's package manager (whatever it is) with a language's package is a separate and thorny issue, which I think can't be "perfectly" solved short of unrealistic rewrite-the-world solutions. E.g., what happens if you do apt-get install cabal" and then use cabal to update itself to the newest version? What happens if you then "apt-get upgrade" and there's a newer version than the one apt installed, but it is older than the one you installed manually? etc.

I do this all the time and haven't ran into a problem yet. Is there something in particular you expect to break?

I install GHC from my distro database and use that to bootstrap my way into whatever Haskell dev environment I feel is suitable.

At the moment that looks like "sudo apt-get install cabal-install" (or whatever the appropriate syntax is) followed by "cabal update && cabal install cabal-install".

I guess this would break if Debian slipped in a new version of GHC behind my back, but they're pretty cautious about that sort of thing, and the fix would be re-building my user-install of cabal-install.

I think the issue here is that we typically put "$HOME/.cabal/bin" at the front of our PATH so that we get the "new" cabal-install that we received from "cabal install cabal-instal"... but if the distro updates it to an even newer version, we won't see that newer version as it's located later in the PATH, and thus we can't rely on our distro packagers to figure out when there's a newer version of various utilities.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

I think that "something" need to be done to make it easier to set up > GHC + cabal, independently of HP (unless HP becomes the "one true way" to install Haskell, which I doubt is the case).

Isn't that what this banner on http://www.haskell.org/ghc/download_ghc_7_6_3 is supposed to signify? "Stop! For most users, we recommend installing the Haskell Platform instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together." For the people who want GHC to include cabal-install, what are the obstacles to using the Haskell Platform instead? One possibility I can see is disk space. The other reason, raised by Carter at the start of this thread, is wanting to use the freshest GHC. Cheers, Ganesh

I guess my point is that the platform should be suitable for almost everyone. That was certainly the way I perceived the intention when it was first launched. How about just extracting the latest cabal binaries from the Platform after each release and making them available for separate download? That way there's no extra burden on the cabal or GHC maintainers and no need to solve the general problem of making more frequent cabal binary distributions. On 25/01/2014 18:27, Carter Schonwald wrote:

the point is: there should be some *easy* way to get/install cabal-install binaries for those who aren't in a situation where haskell platform is appropriate.

I generally regard haskell platform as "for students", "people with enterprise support cycles" and "oh shit, my haskelll install is borked and i need to get things working again right nowwwwww". I understand that certain distros/package managers regard it as a stable substrate (rightfully, cf my remark about support cycles).

But that doesn't preclude people from doing their own setup, and if that is common place (as I believe it is, though i've not done a survey), having binaries at are easy to install is a reasonable goal!

-Carter

On Sat, Jan 25, 2014 at 12:59 PM, Ganesh Sittampalam mailto:ganesh@earth.li> wrote:

> I think that "something" need to be done to make it easier to set up > GHC + cabal, independently of HP (unless HP becomes the "one true > way" to install Haskell, which I doubt is the case).

Isn't that what this banner on http://www.haskell.org/ghc/download_ghc_7_6_3 is supposed to signify?

"Stop!

For most users, we recommend installing the Haskell Platform instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together."

For the people who want GHC to include cabal-install, what are the obstacles to using the Haskell Platform instead?

One possibility I can see is disk space. The other reason, raised by Carter at the start of this thread, is wanting to use the freshest GHC.

Cheers,

Ganesh _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello Ganesh, On 2014-01-25 at 22:44:44 +0100, Ganesh Sittampalam wrote:

How about just extracting the latest cabal binaries from the Platform after each release and making them available for separate download?

That way there's no extra burden on the cabal or GHC maintainers and no need to solve the general problem of making more frequent cabal binary distributions.

Btw, unless I'm missing something, from http://www.haskell.org/platform/linux.html it doesn't look like there's a binary tar-ball distribution of the HP for Linux in the style of the GHC binary distribution tarballs, from which the executable could be extracted. What's more, the page refers to distribution-specific packages, which potentially lag behind wrt to the latest released HP version, and they don't allow for parallel installs of multiple HP versions (as opposed to the GHC binary tarball distributions) Greetings, hvr

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 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.

...

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

On 20/01/2014 00:02, Carter Schonwald wrote: 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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 wrote:

If you can't find any better options, I can try to run a buildbot on a laptop that's probably mostly online.

...

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

On 21/01/2014 19:32, Johan Tibell wrote: 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 mailto:ganesh@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@haskell.org mailto:Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel:

On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:

...

I feel this blurs the roles of GHC and the Platform.

IMO, that's a weak argument, as the roles are already blurred:

GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead.

At least haddock is bound to the specific GHC version. I don't know how strict is the relation between hp2ps and hpc and GHC. Cabal-install on the other hand can be exchanged.

Moreover, GHC ships with a set of base libraries (which, and thus effectively GHC forces 20 or so packages (fixed to specific package versions) into the HP and takes away authority from the HP release process.

Yes, that's unfortunate. My prefered solution would be that GHC is only shipped with package 'ghc', whereas 'base', 'Cabal', 'containers' et.al. can be built by the user. Btw. on Debian/Ubuntu I can install cabal-install from the distribution repositories. With this one I can build newer versions of cabal-install.

* Herbert Valerio Riedel [2014-01-22 12:55:53+0100]

On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote:

...

Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel:

...

On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:

...

I feel this blurs the roles of GHC and the Platform.

IMO, that's a weak argument, as the roles are already blurred:

...

GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead.

At least haddock is bound to the specific GHC version.

When I look at http://hackage.haskell.org/package/haddock, there are multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all declared to work with ghc == 7.6.*, that is, 5 haddock versions compatible with 3 released versions of GHC 7.6. So while it may be bound to a major version of the GHC API, haddock can obviously have more releases than GHC has releases (otherwise it could just carry GHC's version), and can therefore be updated.

Henning could be more specific in his claim that "haddock is bound to the specific GHC version". I guess he's referring to the binary rather than source distribution's compatibility. Assuming static linking w.r.t. the ghc package, the incompatibility with a different GHC version could still arise from the fact that haddock (as any other GHC API using application, I suppose) makes use of the GHC's lib directory, although I don't know the details. If we are talking about installing haddock from source (using cabal-install), then it should be no different from installing, say, ghc-mod. Roman

On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel wrote:

On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:

...

I feel this blurs the roles of GHC and the Platform.

IMO, that's a weak argument, as the roles are already blurred:

GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead. Moreover, GHC ships with a set of base libraries (which, and thus effectively GHC forces 20 or so packages (fixed to specific package versions) into the HP and takes away authority from the HP release process. But now the difficult to explain thing is that GHC also bundles the library part of CABAL but deliberately leaves out CABAL's frontend tool `cabal-install` only to justify the existence of the HP a bit more? :-)

Cabal is part of GHC's build process and GHC uses data types from Cabal. That's why it's there. It's not because we want Cabal to be included (just like we don't want to ship those libs.) These are technical limitations.

I think there's now hosted official cabal install binaries online. I'm Afk but they should be a short google away. Should be linked more prominently though On Saturday, May 3, 2014, Ashley Yakeley wrote:

So I want to install GHC + cabal on a new system, building cabal packages with profiling and documentation. Here's what I have to do:

1. Download, unpack and install GHC.

2. Download and unpack cabal-install, and run bootstrap.sh. As part of the bootstrap, it will download and build a bunch of packages.

3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they were built without profiling or documentation.

4. Call "cabal update" to get a default .cabal/config file.

5. Edit .cabal/config to switch on library-profiling, executable-profiling, and documentation.

6. Build my stuff.

This would be much simplified if binary versions of cabal-install were available. (It would be even simpler if they were just included in the GHC builds -- I could eliminate 2 & 3.)

-- Ashley Yakeley _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm waiting for someone to send me a Windows one. On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley wrote:

I couldn't find them, and they're not listed at < http://www.haskell.org/cabal/download.html> (except OS X), or at < http://www.haskell.org/haskellwiki/Cabal-Install>, or at < http://hackage.haskell.org/package/cabal-install>.

-- Ashley

On 2014-05-03 17:00, Carter Schonwald wrote:

...

I think there's now hosted official cabal install binaries online. I'm Afk but they should be a short google away. Should be linked more prominently though

On Saturday, May 3, 2014, Ashley Yakeley > wrote:

So I want to install GHC + cabal on a new system, building cabal packages with profiling and documentation. Here's what I have to do:

1. Download, unpack and install GHC.

2. Download and unpack cabal-install, and run bootstrap.sh. As part of the bootstrap, it will download and build a bunch of packages.

3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they were built without profiling or documentation.

4. Call "cabal update" to get a default .cabal/config file.

5. Edit .cabal/config to switch on library-profiling, executable-profiling, and documentation.

6. Build my stuff.

This would be much simplified if binary versions of cabal-install were available. (It would be even simpler if they were just included in the GHC builds -- I could eliminate 2 & 3.)

-- Ashley Yakeley _______________________________________________ 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