Subject: Improving the "Get Haskell Experience"
From: Mark Lentczner <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Haskell Libraries <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 12 Jul 2015 16:03:53 +0000
List-Id: GHC development discussion <ghc-devs.haskell.org>

tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.

At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options.

Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan:

*       Haskell Platform becomes the standard way to get GHC and related tools: alex, cabal, happy, hscolour, and stack. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users.
*       Use the stack model for package installation:

   *    The global db has only the GHC packages
   *    There is a package db for each curated set, Haskell Platform becomes one such set
   *    Projects each have their own package db, much like sandboxes.

*       Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that stack can be used to build and install, on as needed, the corresponding Haskell Platform release packages.

We think this plan solves many different community needs:

*       We have a clear way to "get Haskell" that works for a wide variety of use cases.
*       HP installer gets much smaller, and about as minimal as a working installation can get.
*       By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings.
*       By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired.
*       Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work.

To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting stack ready such a distribution; and configuring (or updating) cabal-install to support the three-layer package db scheme. We think we can do this in short order.

We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially ghc, cabal, and stack. We'd like to get your input.

- Michael & Mark