wither the Platform

[Herbert Valerio Riedel]

On 2015-03-25 at 07:21:48 +0100, Mark Lentczner wrote:

[...]

> *The problem is how GHC is released:* It is released as a compiler, and
> minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no
> other tools, and no installer. *This is an insufficient set of things for
> most users.*
>
> At minimum it should also have cabal-install, and the libs so many things
> are built on: async, mtl, text, parsec, vector, etc..., and also common
> tools (like happy, alex, and hscolour). You can argue plus or minus some of
> these, the set could be bigger or smaller, ... basically, it should be the
> Platform.

> We should consider those additional libs as frozen, and tied to the GHC
> release, as the base libs - because that will mean those will be the common
> versions people will build and test against. And they will update as
> frequently as GHC. (If they aren't as stable as all that, or aren't willing
> to be part of that release cycle and constraint, then perhaps they
> shouldn't be in that set!)
>
> Yes, I'm arguing that the GHC release and the Platform release should be
> one and the same. The vast majority of the pain I think stems from the skew
> between these two, and that GHC is not enough. You need something besides
> the GHC release. If that something isn't standard, and/or it lags the GHC
> release, then all the attendant problems creep in.

[...]

While I sympathise myself with bundling cabal-install with GHC bindists,
as that's been (in my perception) the most requested feature from
ghc-bindist users, GHC HQ is trying rather trying strip down the GHC
distribution and dropping packages being installed by default whenever
possible.

E.g. with GHC 7.10.1 we dropped 4 packages (old-locale, old-time,
haskell98, and haskell2010) as those don't need to be part of the
(installed) GHC distribution. Some other packages (xhtml, haskeline,
terminfo) that were recently exposed could be dropped again if we manage
to workaround an unexpected DSO issue. We would even be in the position
(since GHC 7.10) to drop the `Cabal` package from being installed (if it
wasn't for the Cabal spec), as the `ghc` package severed its dependency
on `Cabal` with this release.[1]

Not tying packages to GHC releases gives more flexibility and less
overhead, as we need to synchronise less with upstream maintainers, and
more importantly updates to non-bundled packages can happen
independently of GHC releases and more frequently. Also, it gives 3rd
party packagers more degrees of freedom to select different
cross-sections/subsets of Hackage to define as curated snapshot
(i.e. LTS, Stackage, HP, Linux distributions, NixOS, ...).


Cheers,
  hvr

 [1]: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/7571