[haskell-infrastructure] wither the Platform

[Gershom B]

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