[haskell-infrastructure] wither the Platform

[Anthony Cowley]

> On Mar 23, 2015, at 1: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.

To be clear, I said that package authors know what they are doing for themselves. I don't think they inherently know what is best for beginners, hence the reddit evidence.

> 
> 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.


That's a good start, but not enough. For example, Mark's latest platform build shows OpenGL taking up a lot of space. Plenty of users want to install GHC in a server-like environment where this is a waste. But then OpenGL takes a long time (and apparently many gigabytes of RAM) to build, so we'd rather not require that those who want it rebuild it for each project (I've done this, and it's a drag). Now we face the question of having different platforms for different users, which may be acceptable despite the common claim that there should be a single download so as not to burden new users with a difficult choice. Alternately, if we let our installation tools catch up to our needs, we will have an automatic way to upgrade from a minimal installation to a, say, game development environment. That is, a user says "cabal install OpenGL", and it works, makes future rebuilds of OpenGL unlikely, and doesn't interfere with a program that depends on an older version of OpenGL. We can certainly offer kits of packages for specialized needs, but the main thing is to avoid "blessing" any one set of packages such that I'm stuck with a shared global database based on which platform I downloaded back on day 1 with Haskell.

I chose OpenGL as an example, but a similarly unpleasant experience awaits potential users of our various web server packages. They are big things to install, and have dependency chains that are always itching for a rumble. These packages are some of our community's best software, the old tooling should be updated to support them.

Anthony