On Sun, Mar 22, 2015 at 10:23 AM, Yitzchak Gale
Mark Lentczner wrote:
1) Abandon the Platform…
2) Slim the Platform. Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.
3) Re-conceive the Platform. Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.
I vote for (3) but in a way that it would *not* be much work. We should definitely do the Platform, but with much *less* work.
+1
The most important reason we need the Platform is as a default selection of quality basic libraries. We should not abandon that concept. Curated package sets do not replace that - the Platform is not just packages that build together. Nor do OS packagers. The platform is a community-wide set of basic default packages that are mature, well tested, all work together well, and stable.
The second most important role of the Platform is a web site where you can get a clear picture of how to download and install a default Haskell installation for your platform, and a simple view of where we are in the parade of releases. That should also continue.
The hardest work of the Platform was its role as a way to bootstrap a Haskell installation. That is what made it so hard for HP to keep up with GHC releases, and what consequently gave people the impression that HP is always old. That work doesn't need to be done as part of the Platform anymore. We should leverage other good work people are doing to create installers, and stop doing it as part of the HP process.
The most important part of an HP release should be a cabal package that provides the packages in the platform, at the right versions, with a specification of the recommended GHC version as a pre-requisite.
Perhaps we can also provide an HP-branded slick installer for some platforms that does everything in one click, built as a thin wrapper of some existing installer. But that should not delay the official release of an HP version. It's just a nice-to-have extra.
Once we pare down the work needed for an HP release, we should release new versions of HP quite often - *more* often than GHC releases, not less often.
Another thing we should fix is the (now false) impression that HP gets in the way of installing other packages and versions due to cabal hell. We should make "require-sandbox" the default setting in the cabal config file. I would go further - I would add a cabal feature to create a sandbox automatically unless "--user" or "--global" is specified explicitly. I would make "foo installed" a default constraint (that is easy to override) for all platform packages, which solves virtually all cabal hell problems (assuming you are using a sandbox) and will not keep things old if we release often.
One of the original goals of the HP was to try and reduce cabal hell issues, but we've since seen a great deal of work in trying to solve those problems by other means. Similarly, one of the original goals was to improve Windows installation, but that too seems to have moved on. With these changes in the landscape, it's no wonder the HP doesn't seem to have much public uptake these days. As present, I think we do still need something like HP, albeit recast to fit the new landscape. The goals of Stackage and LTS are quite different, and thus they cannot fill the role that HP does/did. ... For me, the HP has served a couple roles. First (in no particular order): to serve as a one-click install for getting Haskell up and running on a new computer. Second: to serve as a stable and coherent snapshot of the Haskell ecosystem. This latter purpose seems, imo, to be the more important one going forward. In the enterprise setting —including the enterprising FOSS community— it's important to have checkpoints as a way of tracking backwards compatibility. While most developers focus on getting the shiniest newest things, this backwards support is extremely important both for maintaining infrastructures and for introducing new folks to the community; for both these groups, the newest and shiniest things may not be easily available/usable due to economic concerns. The "preserve compatibility with the last X versions" model works well for dependencies like GHC, but it's not always clear (in retrospect) which versions of hackage libraries were the contemporary/standard versions corresponding to each GHC version. Thus, providing these sorts of checkpoints is a necessary part of community building— for commercial enterprise, FOSS enterprise, and newcomers alike. Now that we have our foot in the door with various distros, the goal of providing checkpoints can also help to satisfy the one-click install goal, since the checkpoint provides distro managers guidance on how to support a coherent snapshot of the crucial/main libraries needed to get up and running. (Also, this could potentially provide an avenue for reducing the work involved in releasing the HP; that is, by relying on distros to deal with the distribution aspect, we could focus more on just building/testing the configurations for each release.) ... As mentioned elsewhere in the thread, the outdatedness image of the HP is definitely a problem. The salient solution here is to try and release more often than we do now. Of course, with the amount of work the HP currently takes for each release, that's not really tenable. When the HP started we all knew it'd be a bunch of work, but that work seemed like a good idea at the time. Now that the goalposts have moved, that work seems more like an unnecessary burden. So, what could the HP offer today which would be worth the work it takes to do so? -- Live well, ~wren