Fwd: 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