wither the Platform

[Michael Snoyman]

Thanks for linking to that Mike, I'd actually forgotten that I'd written
that :). Those are all very concrete issues people run into with the
platform regularly, but I'd like to point out a meta issue: the platform
tries to do too much, and in a non-composable manner. As I pointed out
previously, it's providing a tools installer, choosing blessed libraries,
pegging certain library versions, and selecting a distribution manner for
those libraries. Even if the other issues were all addressed, I still
believe the current trajectory of the platform is problematic, because it
is necessarily removing choice.

When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in
my mind at least) was to allow individual tools to target individual goals.
I don't expect every use case to be served by a curated package set (like
LTS), so making that an optional feature of tooling makes sense. Similarly,
almost all users (excepting some people playing with bleeding-edge GHC)
will benefit from having an easy-to-use GHC+cabal-install installation, but
a large set of users (specifically Hackage package authors) need a way to
compile against different versions than the HP-blessed ones for testing
purposes.

And now a completely separate point: the current functioning of the HP
process seems very much at odds with the way people actually write and
release packages. Some examples:

* Having to go through an extra step of requesting that a package version
is bumped is tedious, and resulted in a buggy attoparsec being released in
HP
* Requiring package authors to endure long debate periods before the
package is accepted scares people off from wanting to participate
* A number of months back, the HP was used as a vehicle to push the PVP
agenda as well, which completely alienated some people from wanting to
participate (ironically, the package being pushed instead was not PVP
compliant either, go figure). The practical result to that is we currently
have no plans at all for getting TLS/HTTPS support into the platform, and
everyone's tooling (cabal-install) is far less secure than it should be.
* Authors want the freedom to quickly release new versions to their users,
especially for bug fixes. While in theory the HP is set up to do bugfix
releases, in practice this has never happened. In that sense, it is often
preferable from the eyes of a package author *not* to have his/her package
in the HP, as then users are better served

As long as I'm writing a long email, I want to point out one other thing. A
lot of the points being raised in this thread are discussing an idealized
view of what the HP could become. I'm fully in favor of improving it (like
I said, that's why I tried working with Mark on GPS Haskell and integrating
with Stackage). However, we need to accept the reality of the situation
today. Could the windows HP installer be improved like MinGHC to include
MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work
around the global package database issues we've been mentioning? Yes, and I
support such moves. But we need to acknowledge current deficiencies, and
plot out a course of action to solve them. And given that this thread
started by lamenting how much effort the platform currently takes to
maintain, I'm concerned about those improvements actually occurring.

On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer <mwm at mired.org> wrote:

> On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones <simonpj at microsoft.com
> > wrote:
>
>>  So that was the plan.  I still think it’s a good plan.  But it clearly
>> is not working well, and I’m hazy about why.  Possible reasons:
>>
>
> Possibly relevant is the stackage commentary on HP at
> http://www.stackage.org/install#why-not-haskell-platform:
>
> • On Windows, it does not provide a complete environment (missing MSYS).
> • By placing a large number of packages in the global package database,
> Haskell Platform installations are more easily corrupted.
> • The choice of package versions conflicts with the needs of many commonly
> used packages.
> • Some of the package versions included with the platform have known and
> severe bugs, and cannot be reliably upgraded.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150325/49a7bc23/attachment.html>