Haskell Platform Plans

Fri Nov 13 05:00:46 GMT 2015

Thank you. I like the direction you're taking this. I look forward to
helping in whatever ways I can.

On Thu, Nov 12, 2015 at 8:47 PM, Gershom B <gershomb at gmail.com> wrote:

> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20151113/bdd32823/attachment.htm>