
On Windows, the reason I used to use the Platform was that it came
with an installed network library, and installing the network library
on Windows is a real pain (and often fails). Unfortunately it was
incredibly brittle, a single attempt at upgrading network from some
newer package usually trashed my Haskell install and required a wipe
and restart.
Nowadays I use https://github.com/fpco/minghc which can actually
install network, and I've had zero problems. I can get up to the
platform with one invoke of cabal, and if someone decides to require a
new network, it just works.
I think the Platform now gives a worse user experience on Windows, so
the ideas (or names) probably need migrating around.
Thanks, Neil
On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus
Mark Lentczner wrote:
I'm wondering how we are all feeling about the platform these days....
I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.
Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.
That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.
The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.
I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:
*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.
*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.
*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.
Thoughts?
Thanks a lot for your hard work on the platform!
I myself am an avid user of the platform (OS X), because for me, it's the easiest way to install Haskell on a new machine; I just did so the other day.
The only time when the platform seems to be a handicap is when a new version of GHC is being released and I would have to update my packages. Usually, I don't test them with the new version and rely on pull requests instead.
Best regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I'd like the haskell platform to include all of LTS haskell. That includes
a very broad set of packages so you don't need to install many other
packages even as an advanced user.
Maybe there could also be a nightly release which includes stackage
instead?
It would save a lot of time even for experienced users, since they get
stackage precompiled.
However, such a distribution should be designed such that cabal install
just works, so it should probably be based on winghc on Windows.
The only problem I can see with this is the size of such a package, not
sure if it would be acceptable?
Neil Mitchell
On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart.
Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems. I can get up to the platform with one invoke of cabal, and if someone decides to require a new network, it just works.
I think the Platform now gives a worse user experience on Windows, so the ideas (or names) probably need migrating around.
Thanks, Neil
Mark Lentczner wrote:
I'm wondering how we are all feeling about the platform these days....
I notice that in the new Haskell pages, the Platform is definitely not
On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus
wrote: the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.
Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.
That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.
The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.
I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:
*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.
*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.
*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.
Thoughts?
Thanks a lot for your hard work on the platform!
I myself am an avid user of the platform (OS X), because for me, it's the easiest way to install Haskell on a new machine; I just did so the other day.
The only time when the platform seems to be a handicap is when a new version of GHC is being released and I would have to update my packages. Usually, I don't test them with the new version and rely on pull requests instead.
Best regards, Heinrich Apfelmus
-- http://apfelmus.nfshost.com
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sun, Mar 22, 2015 at 10:17 AM, Neil Mitchell
On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart.
Slightly OT: If you ever want to prevent cabal from trying to install a different version of a package (since you know it won't work, or will break things) you can put something like this in your cabal config: constraint: network installed I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network. Erik

On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: [...]
I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network.
Why isn't it possible to reinstall TH (unless you also need to depend on the `ghc` package)? We even explicitly allowed template-haskell to be reinstallable again in Cabal as there didn't seem any reason to forbid it anymore (it's no different than e.g. `bytestring` which is reinstallable as well): https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f73... Cheers, hvr

On Sun, Mar 22, 2015 at 11:24 AM, Herbert Valerio Riedel
On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote:
[...]
I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network.
Why isn't it possible to reinstall TH (unless you also need to depend on the `ghc` package)? We even explicitly allowed template-haskell to be reinstallable again in Cabal as there didn't seem any reason to forbid it anymore (it's no different than e.g. `bytestring` which is reinstallable as well):
https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f73...
This was based on my experiences from some time ago. Looking at it now, I think it was just that the dependencies for template-haskell were too loose, i.e. it allowed different major versions of base. When a new version of GHC was released and I was trying it out, it would always try to install the older version, and this never worked. Now that you fixed these constraints (thanks!) it seems you can reinstall, as long as it's the same (major) version. It still prints this ominous warning even in a sandbox: Warning: The following packages are likely to be broken by the reinstalls: ghc-7.8.3 But everything seems to be fine when passing --force. So I guess I can remove the constraint... Erik

The original reason for the cabal hack that prevented it from trying to
reinstall template-haskell is that almost every time someone did this it
broke, silently. Then five packages later something would use template
haskell, and you'd get completely nonsensical error messages, and someone
_else_ would get the bug report. Sure there might have been a scenario in
which an expert who is working on ghc may want to reinstall the
template-haskell to get a new point release, but TH has never worked across
multiple GHC versions, and old versions shipped with very wide bounds.
Now, of course, maintainers and the trustees have the ability to
retroactively narrow bounds (and you've already done so for
template-haskell), so this view is dated. template-haskell should just be
reinstallable like everything else now.
-Edward
On Sun, Mar 22, 2015 at 6:24 AM, Herbert Valerio Riedel
On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote:
[...]
I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network.
Why isn't it possible to reinstall TH (unless you also need to depend on the `ghc` package)? We even explicitly allowed template-haskell to be reinstallable again in Cabal as there didn't seem any reason to forbid it anymore (it's no different than e.g. `bytestring` which is reinstallable as well):
https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f73...
Cheers, hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Sun, 2015-03-22 at 09:17 +0000, Neil Mitchell wrote:
On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart.
Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems.
Can we just include this fix into the platform installers? As Mark says, the Platform has decent automated build & test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to "min" vs "max" installers. Duncan

Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems.
Can we just include this fix into the platform installers?
Yes. MinGHC was an experiment in seeing if we could do a Windows installer that worked with Network. We can, so the platform should. However, MinGHC has a few other advantages. It provides a switcher so you can put all the switchers on your PATH and type "minghc-7.8.3" to get that version of GHC selected. Again, the platform could gain that feature. MinGHC also ships with GHC 7.2, 7.4, 7.6 and 7.8. Hopefully as soon as 7.10 is out within days we'll have a MinGHC for it. I'd also really like to start shipping MinGHC installers for GHC release candidates and even nightly GHC release candidates.
As Mark says, the Platform has decent automated build & test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to "min" vs "max" installers.
Indeed, it has nothing to do with how many packages are shipped. As long as my installer ships with enough to install the packages I care about, then I don't care about min vs max. That said, all I really care is what GHC the platform includes, everything else is redundant (to me). As such having a link to a platform with each GHC version would be handy. Thanks, Neil
participants (6)
-
Benno Fünfstück
-
Duncan Coutts
-
Edward Kmett
-
Erik Hesselink
-
Herbert Valerio Riedel
-
Neil Mitchell