Hi, Simon Hengel wrote:

Where would something like the HP actually make sense?

In my experience, the Haskell Platform makes it significantly easier to use Haskell on Windows. On Windows and/or for the typical Haskellers on Windows, it is hard to build a package that depends on external C libraries or uses a configure script, however trivial. This is because on Windows, there is no way to manage installed C libraries without understanding C development. But most Windows users are not C programmers, and some Windows Haskellers even learn Haskell as their first programming language. In extreme cases, ghc and cabal are the first command-line tool they learn. So on Windows, before the Haskell Platform was introduced, `cabal install some-random-package` usually failed for some dependency that required a C library. With the Haskell Platform, `cabal install some-random-package` usually works. I guess there are two effects: 1. The Haskell platform seems to bundle some packages that require external C libraries or configure scripts. The network package comes to mind. 2. The existence of the Haskell platform encourages non-Windows developers to avoid dependencies that are not in the Haskell platform. Because of effect 1, this translates to non-Windows developers avoiding dependencies that are hard to install on Windows. So from the perspective of using Haskell on Windows, the Haskell Platform is very successful, and installing it is good advice. If anything, it should be bigger, not smaller. And it should focus on libraries with external dependencies. So could we make a Haskell-on-Windows-Platform and drop the Haskell Platform for the other platforms? This would give Haskellers on Windows the first effect, but it would disable the second effect. I'm not sure how much the first effect is worth without the second. Why should we care about Haskellers on Windows? I think there are some important classes of new Haskellers that are on Windows, at least initially, and if we want to convert them to long-time Haskellers, we need to support them in their context. For example, here are three reasons to start your Haskell experience on Windows: 1. You might be a student at a university where the lab computers run Windows. A minimal installation without excellent support for libraries would be fine for following a lecture on Haskell, but you will not take Haskell serious if it doesn't give you easy access to libraries. In fact, installing Haskell libraries can be very easy, but only if you get the external dependency issue out of the way. 2. You might be a not-yet-programmer who wants to use a embedded DSL for your domain, and you're on Windows "by default" or because of the tradition in your field. We like to claim that Haskell is good for embedded DSLs, so we should support this usage scenario. 3. You might be a not-yet-programmer who wants to use an external DSL for your domain, and you're on Windows as above, and you want to become a power-user of the DSL. So maybe you start reporting bugs and are asked to `cabal install` the development version to check fixes. Or maybe you want to copy-and-adapt a little Haskell program that uses a library interface to the DSL for scripting purposes. We see both of this happening for pandoc, for example. Also, Haskell is a high-level language, and it would be somewhat silly if Haskell programs would not be easily portable due to low-level issues. Tillmann

On Tue, Apr 15, 2014 at 11:45:22AM +0300, Roman Cheplyaka wrote:

* Simon Hengel [2014-04-15 13:02:38+0800]

...

...

Would it be worthwhile to create a "Minimal Haskell Platform" to create a truly common platform that everybody would be happy using?

I think most Haskell developers use a reasonably recent version of GHC (that would currently still be 7.6.3 for me) and the latest version of cabal-install. Everything else can be installed with cabal-install.

So yes, I think we should just have an easy way to get that minimal setup (+ most importantly don't recommend something to beginners that we don't use ourself).

Where would something like the HP actually make sense? For stuff that has external dependencies that are not easily installable with cabal-install (like curses bindings, SSL support, etc.). We have none of this in the HP. So I think currently we just have additional costs, but no benefits (+ we harm innovation by arbitrarily "endorsing" random packages).

Agreed.

As Tillmann notes, HP is indispensable on Windows, but that is a side effect. Indeed, HP as a simple way to conveniently install the bits that are otherwise hard to install makes perfect sense.

When looking at `network` specifically, I think it does not even have external dependencies, it just needs a C compiler and GNU autotools. So if we care about Windows support, couldn't we just bundle MingGW with a minimalistic GHC + cabal-install distribution. That would not only solve the network case, but also work for other packages that include some C files in the cabal package or need autotools for whatever reason. Cheers, Simon

Hi, On 15 April 2014 12:11, Simon Hengel wrote:

When looking at `network` specifically, I think it does not even have external dependencies, it just needs a C compiler and GNU autotools. So if we care about Windows support, couldn't we just bundle MingGW with a minimalistic GHC + cabal-install distribution. That would not only solve the network case, but also work for other packages that include some C files in the cabal package or need autotools for whatever reason.

GHC on Windows already includes MinGW, but you also need MSYS for configure scripts. I do want to ship MSYS with the HP installer, but haven't got around to integrating it yet.

On Tue, Apr 15, 2014 at 3:45 AM, Roman Cheplyaka wrote:

on, I don't care about HP. The only time when I remember about it is when I tell novices how they can "install Haskell". But again, this has nothing to do with the bundled cabal packages, only with the way of installing ghc/cabal/etc.

This points out at least one other benefit of HP: it provides a larger set of libraries for people learning Haskell to get started with before having to learn how to deal with cabal and the possibilities of cabal hell. It may be that this isn't real - that the recent and good or popular tutorials all work fine with just GHC, in which case ignore me. On the other hand, if they all deal with cabal at one point or another, possibly HP needs better curation: audit what's there to make sure it's the best choice, drop things that aren't useful, expand it to include critical libraries that are required by the tutorials, etc.

On 2014-04-15 09:45, Roman Cheplyaka wrote:

* Simon Hengel [2014-04-15 13:02:38+0800]

...

...

Would it be worthwhile to create a "Minimal Haskell Platform" to create a truly common platform that everybody would be happy using? I think most Haskell developers use a reasonably recent version of GHC (that would currently still be 7.6.3 for me) and the latest version of cabal-install. Everything else can be installed with cabal-install.

So yes, I think we should just have an easy way to get that minimal setup (+ most importantly don't recommend something to beginners that we don't use ourself).

Where would something like the HP actually make sense? For stuff that has external dependencies that are not easily installable with cabal-install (like curses bindings, SSL support, etc.). We have none of this in the HP. So I think currently we just have additional costs, but no benefits (+ we harm innovation by arbitrarily "endorsing" random packages). Agreed.

As Tillmann notes, HP is indispensable on Windows, but that is a side effect. Indeed, HP as a simple way to conveniently install the bits that are otherwise hard to install makes perfect sense.

However, nowadays most attention goes not to that, but to choosing ordinary cabal packages to be bundled with HP. I see little value in that.

As a way to ensure the "installability" of packages, Stackage now does a far greater job than HP by:

- having much wider selection of packages, and making it almost trivial to incorporate new ones; - constantly building packages and running tests; - notifying maintainers about broken packages and packages with restrictive upper bounds.

In other words, it ensures that Stackage packages are installable at any time with cabal. (Well, strictly speaking, there may be a delay between when a problem is reported by Michael and when it's fixed by the maintainer.)

Apart from that, HP "arbitrarily endorses" its packages and forces them into stability mode. Whether it is a good thing or not is another argument and depends on one's perspective. I know that some people find it important (and I'm well aware of their reasoning).

Personally, with my hats of

* an open source libraries developer/maintainer * a personal Haskell user * a commercial Haskell user

on, I don't care about HP. The only time when I remember about it is when I tell novices how they can "install Haskell". But again, this has nothing to do with the bundled cabal packages, only with the way of installing ghc/cabal/etc.

Agreed with Simon and Roman here, The initial goals of the HP were good, but I think a smaller minimal haskell HP/installer (really for windows) would make more sense now considering the situation. I think for something like the HP to be successful (according to its goals), you would need to have full time staff developing it together in one common place. So currently, it doesn't really provides batteries, but merely a base++ with an extra set of "random" packages (opengl, cgi, ..). And, at the same time, it doesn't provide that much more API stability either (across multiple versions of the HP). -- Vincent

On 2014年04月16日 09:56, Mikhail Glushenkov wrote:

On 15 April 2014 03:35, Travis Cardwell wrote:

...

In a recent /r/haskell post [1], user mightybyte commented:

...

This. The Haskell Platform installs a bunch of packages for you in --global. My experience is that this inevitably leads to problems if you're doing significant Haskell development. The best thing to do is to minimize the number of packages installed as --global. The way to do that is to install GHC directly and avoid using the Haskell Platform or Haskell distributions provided by your OS.

The post you quote doesn't provide information about specific problems with this setup. I'd be interested to hear about them.

Personally, I have not run into problems either, as newer versions of packages can be installed into sandboxes. I BCCed the original commenter, to make sure that he is aware of this thread, and I put a request for specific examples of problems in the Reddit discussion: http://www.reddit.com/r/haskell/comments/23224w/minimal_haskell_platform/ I also asked in #haskell, but nobody who is currently online seems to have examples. Cheers, Travis