wither the Platform
duncan.coutts at googlemail.com
Mon Mar 23 22:51:17 UTC 2015
On Sat, 2015-03-21 at 10:54 -0700, 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.
There was a big argument about this. I was on the loosing side. :-)
> 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.
I think it is worth it, and the issues that people are complaining about
wrt the platform vs minimal installers can be fixed.
> 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.
Right, I think there's still a great deal of value in having a simple
recommendation for new users.
One of the points of argument was that some people were arguing that the
minimal installers are better for new users. I disagree, but certainly
there is one issue that could be fixed that'd go a long way to resolving
the particular use case with new users that was raised.
> 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:
Well, the people who like it don't really complain. But yes, things need
> *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.
I'm not sure that slimming is really needed. But I agree with the GPS
approach. The current set is too small in the sense that it doesn't
cover lots of things people need, and the GPS approach should solve
that. We don't need to promise such high QA for the extended set, we
just need to make sure they build together.
We need to remember that one of the purposes of the platform as
originally conceived is to get people to sync on the versions of their
deps that they're using at the moment. This is where the GPS approach
shines, but it still makes sense to have some core set at the middle of
that. It's true that advanced users don't need lots of things
pre-installed, but they sill benefit from other developers synchronising
on versions of deps, so that they can have more things work together
On the argument that the platform is too big, the primary issue there is
that people want to make new sandboxes that are more minimal, and with
cabal's current behaviour of basing all sandboxes off of the global
package db, and the platform installing lots of packages globally then
we get a conflict.
But the solution is simple: make cabal sandboxes not be based off of
everything that is globally installed, make new sandboxes be really
minimal (though the ghc/platform installers could help with identifying
what is the minimal subset).
More information about the ghc-devs