wither the Platform

[wren romano]

On Sun, Mar 22, 2015 at 10:23 AM, Yitzchak Gale <gale at sefer.org> wrote:
> Mark Lentczner wrote:
>> 1) Abandon the Platform…
>>
>> 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 vote for (3) but in a way that it would *not* be much work.
> We should definitely do the Platform, but with much *less* work.

+1

> The most important reason we need the Platform is as
> a default selection of quality basic libraries. We should not abandon
> that concept. Curated package sets do not replace that - the
> Platform is not just packages that build together. Nor do OS
> packagers. The platform is a community-wide set of basic default
> packages that are mature, well tested, all work together well,
> and stable.
>
> The second most important role of the Platform is a web site
> where you can get a clear picture of how to download and install
> a default Haskell installation for your platform, and a simple view
> of where we are in the parade of releases. That should also continue.
>
> The hardest work of the Platform was its role as a way to bootstrap a
> Haskell installation. That is what made it so hard for HP to keep up
> with GHC releases, and what consequently gave people the impression
> that HP is always old. That work doesn't need to be done as part of the
> Platform anymore. We should leverage other good work people are
> doing to create installers, and stop doing it as part of the HP process.
>
> The most important part of an HP release should be a cabal package
> that provides the packages in the platform, at the right versions, with
> a specification of the recommended GHC version as a pre-requisite.
>
> Perhaps we can also provide an HP-branded slick installer for some
> platforms that does everything in one click, built as a thin wrapper of
> some existing installer. But that should not delay the official release
> of an HP version. It's just a nice-to-have extra.
>
> Once we pare down the work needed for an HP release, we should
> release new versions of HP quite often - *more* often than GHC
> releases, not less often.
>
> Another thing we should fix is the (now false) impression that HP
> gets in the way of installing other packages and versions due to
> cabal hell. We should make "require-sandbox" the default setting
> in the cabal config file. I would go further - I would add a cabal
> feature to create a sandbox automatically unless "--user" or
> "--global" is specified explicitly. I would make "foo installed" a
> default constraint (that is easy to override) for all platform packages,
> which solves virtually all cabal hell problems (assuming you are
> using a sandbox) and will not keep things old if we release often.

One of the original goals of the HP was to try and reduce cabal hell
issues, but we've since seen a great deal of work in trying to solve
those problems by other means. Similarly, one of the original goals
was to improve Windows installation, but that too seems to have moved
on. With these changes in the landscape, it's no wonder the HP doesn't
seem to have much public uptake these days.

As present, I think we do still need something like HP, albeit recast
to fit the new landscape. The goals of Stackage and LTS are quite
different, and thus they cannot fill the role that HP does/did.

...

For me, the HP has served a couple roles. First (in no particular
order): to serve as a one-click install for getting Haskell up and
running on a new computer. Second: to serve as a stable and coherent
snapshot of the Haskell ecosystem. This latter purpose seems, imo, to
be the more important one going forward.

In the enterprise setting —including the enterprising FOSS community—
it's important to have checkpoints as a way of tracking backwards
compatibility. While most developers focus on getting the shiniest
newest things, this backwards support is extremely important both for
maintaining infrastructures and for introducing new folks to the
community; for both these groups, the newest and shiniest things may
not be easily available/usable due to economic concerns. The "preserve
compatibility with the last X versions" model works well for
dependencies like GHC, but it's not always clear (in retrospect) which
versions of hackage libraries were the contemporary/standard versions
corresponding to each GHC version. Thus, providing these sorts of
checkpoints is a necessary part of community building— for commercial
enterprise, FOSS enterprise, and newcomers alike.

Now that we have our foot in the door with various distros, the goal
of providing checkpoints can also help to satisfy the one-click
install goal, since the checkpoint provides distro managers guidance
on how to support a coherent snapshot of the crucial/main libraries
needed to get up and running. (Also, this could potentially provide an
avenue for reducing the work involved in releasing the HP; that is, by
relying on distros to deal with the distribution aspect, we could
focus more on just building/testing the configurations for each
release.)

...

As mentioned elsewhere in the thread, the outdatedness image of the HP
is definitely a problem. The salient solution here is to try and
release more often than we do now. Of course, with the amount of work
the HP currently takes for each release, that's not really tenable.
When the HP started we all knew it'd be a bunch of work, but that work
seemed like a good idea at the time. Now that the goalposts have
moved, that work seems more like an unnecessary burden. So, what could
the HP offer today which would be worth the work it takes to do so?

-- 
Live well,
~wren