Haskell Platform Plans

[Gershom B]

Dear all,

As you know, Mark has passed on the Haskell Platform maintainer hat to me.

I wanted to give a heads-up on current plans to keep folks in the loop.
This message has three sections, first the 7.10.3 release, next the 8.0
release, and finally some general musings on fiddly details and future
plans.

1) 7.10.3

The 7.10.3 release candidates have been out for windows and unix for a bit.
As I understand it there is still work underway on the mac build, but that
will hopefully be coming shortly. The plan is to release a new platform
roughly simultaneously. This platform will work essentially as in the past,
for two reasons. First, because it is the last release in the 7.10 series
and should be seen like the 7.10.3 compiler as just incorporating some
necessary patches rather than any serious changes. Furthermore, the future
plans underway rely on a few patches to cabal which have been merged, but
are not yet in any existing cabal-install release. A few packages have
received minor version bumps, as follows:

PACKAGE           7.10.2-a   latest
-------------------------------------------
case-insensitive  1.2.0.4   1.2.0.5
fgl               5.5.2.0   5.5.2.3
GLUT              2.7.0.1   2.7.0.3
GLURaw            1.5.0.1   1.5.0.2
HUnit             1.2.5.2   1.3.0.0
OpenGL            2.12.0.1  2.13.1.0
OpenGLRaw         2.5.1.0   2.6.0.0
primitive         0.6       0.6.1.0
syb               0.5.1     0.6
scientific        0.3.3.8   0.3.4.2
StateVar          1.1.0.0   1.1.0.1

A few packages were held back due to dependency issues (notably zlib) and
additionally, packages shipped with ghc were held back to the versions that
will be shipped with 7.10.3.

2) 8.0

We also plan to ship a new platform concurrently with the ghc 8.0 that
should be released early next year.

That platform will implement some long-discussed and requested changes.
First, the platform already ships with msys on windows. However, it does
not do so in a way that lets you, as with minGHC, install the network
library directly, or for that matter install directly other libraries that
use build-type configure. This is because the msys binaries don't get
placed into the path, by design. The new platform will ship with a newer
cabal, incorporating a patch (pull request #2480) that uses the
extra-prog-path setting for build-type: configure. This should allow
network and other things reliant on build-type: configure to directly cabal
install. The goal for the platform on windows will be that any packages
binding to msys libraries _should_ be cabal installable without hassle. If
you maintain a library that you think would be a good test-case for this,
please drop a line so we can work together towards this goal.

Second, the default platform will be _minimal_. That is to say that it will
_only_ install into the global package database those packages that are
directly shipped with ghc, and not any additional platform packages.

"Blessed" platform packages will however still be shipped as a "default
user cabal.config" file, so in a setting where users want to work
unsandboxed, their versions of platform libs will remain pegged to those
chosen by the platform, should they not choose to alter their settings. In
a sandboxed setting, or in the presence of a local cabal.config generated
by a freeze, those constraints will be disregarded.

Furthermore, it is likely but not certain that the "nix-like cabal" or
"no-reinstall cabal" will be available for the 8.0 release. If this is the
case, users will be able to operate in an unsandboxed environment without
conflicts, as multiple instances of the same version of a package, with
different dependency choices, will be able to live side-by-side.

Third, the platform will ship not only with cabal-install, but also with
the stack tool, so that users can choose either workflow, depending on
their project or preferences. A number of people have adopted the stack
tool, and many beginners have reported success with it as well, so it will
be good to provide that functionality out of the box with every platform
install.

Time and resources permitting we would also like to ship a platform version
_with_ the platform libraries prebuilt and included, as that is also a use
case that some people continue to like. However, this is a secondary
priority, and contingent on us getting our build infrastructure into a good
enough shape to make this not too much extra hassle.

I'm excited about these changes, and confident we can get their in a
timespan that matches the 8.0 release of ghc.

3) Generalities

As I mentioned, it would be good to have a more uniform build
infrastructure. Generally, I have put out some feelers and am working
towards extending the ghc nightly buildbot infrastructure to both cover
more platforms and also cover more tools -- not only ghc, but cabal, the
platform, perhaps haddock, ghcjs, etc. This way we can get an economy of
scale and many of our core tools will be able to all share regular
automated builds across many platforms. If you like CI/buildbot systems and
would like to help out with this project, please reach out.

Also, once we've modernized and fixed up the core platform installer tech,
it would be nice to move back to the process of making the platform a good
set of blessed libraries -- taking more proposals for additions to it,
looking to cull libraries that are no longer widely used, etc. As part of
this I intend to move the haskell-platform list off our deprecated
community.haskell.org infrastructure and onto mail.haskell.org with our
other active lists.

Finally, I'm happy to be maintainer of the platform through this period of
change and transition, but at some future point, as things get sorted out
and the release process becomes more standard and mechanical, I would very
much like to pass this responsibility on. I have had some nibbles of
offers, but if other people want to begin to get involved, please let me
know and we can start to get small contributions from you so that you can
become familiar with the various tech and systems involved.

The Haskell ecosystem is a team effort, a collective project, and volunteer
driven. In my modest experience hacking on the various systems involved
(cabal, cabal-install, hackage, the platform build, etc.) some are a bit
confusing, but I have always found helpful contributors willing to explain
things and review patches, and to help think about and diagnose problems.
And none of the code has been as confusing as things I've had to wade
through for employment-related purposes :-). So when this stuff doesn't
work as well as we'd like, we can investigate together, and then put our
heads together and figure out how to improve it together. Furthermore, it
can be very satisfying to do so, because the impact of those improvements
makes itself widely felt. I look forward to more people joining in!

Best,
Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151112/b7c01cc0/attachment.html>