[haskell-infrastructure] wither the Platform

[Andrew Farmer]

I think the fact that we now have these minimal installers floating
around is evidence that there is demand for that.

I personally just download the latest bindist from the GHC site and
bootstrap cabal myself. Partly this is because my work requires me to
have the latest GHC, so maybe I'm not in the HP's target demographic.
That said, I would love if there was a platform that just did that (+
whatever is needed to get that to work). Maybe at the end of the
minimal install, give me a choice between stackage and hackage and set
the remote-repo in my cabal file appropriately.

I was excited by all Mark's (and other's) recent work on the platform,
because it sounded like the new build system would allow it to track
GHC much more closely. To me, the value of the HP (and why I still
recommend it to people) was always that it is a quick way to get ghc +
cabal on your system. Have a curated set of recommended packages was
neither here nor there (until they get way out of date, as Michael
pointed out with aeson 0.6.2.1). Finding good libraries seems like a
problem that google + hackage 2 + stackage solves well nowdays.

On Mon, Mar 23, 2015 at 12:19 PM, Gershom B <gershomb at gmail.com> wrote:
> On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley <acowley at gmail.com> wrote:
>>
>> I don't understand this attitude. You say that neither new users nor package
>> authors agree with your stance on the HP, so you want to force their hands.
>> Presumably package authors know what they're doing for themselves, and the
>> majority of evidence we have is that new users who stick with the language
>> do not like the way the HP works
>> <https://reddit.com/r/haskell/comments/2zts44/wither_the_platform/>.
>
> No, this is not what I said. I was explaining that it rather
> difficult, even if we wanted to force their hands, to imagine that we
> could do so. I will say that I do not share your belief that package
> authors know what they are doing, in general. If they did, I would
> imagine that nearly all packages would ensure they would work with the
> current platform. But getting programmers to all agree on something
> like that is herding cats, and all it takes is a few people saying
> "feh on the platform" but nonetheless producing otherwise good
> packages that come into widespread use to _in general_ mean that many
> packages which directly or indirectly want to use those dependencies
> must also now split off from support for the platform.
>
> So I agree that people have voted with their feet, and we need to
> catch up to that.
>
> In fact, it seems to me from this discussion that there are only _two_
> things we need to do to make the platform the recommended install path
> for all platforms again:
>
> 1) Incorporate the improvements to windows builds that have been
> pioneered by the MinGHC project (in particular so that
> platform-installed windows ghc can build the network package properly,
> and perhaps even the GL stuff).
>
> 2) Address the problem that in a sandbox you will get a different
> install plan depending on your global package db. I would suggest this
> be done by setting a default preference of the sandbox to ignore
> global packages, and allow that to be overridden with an easily
> configurable flag or setting or the like. That way, new users can pay
> the longer compile price for a guaranteed-safer experience, and more
> experienced users can choose to use / build up a broader library of
> packages they can share across sandboxes.
>
> (Certainly some "nix-like tricks" in cabal could also help address the
> repeated builds problem, but a flag can be implemented much more
> quickly as a short-term measure).
>
> All that said, I think it would _still_ be better if more package
> authors paid attention to backwards-compatibility across releases, and
> it would _still_ be better for new users if they didn't go off and
> bash their heads against the newest and least stable packages around.
> But that is indeed a different problem.
>
> Cheers,
> Gershom
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>