Improving the "Get Haskell Experience"
gershomb at gmail.com
Sun Jul 12 16:19:19 UTC 2015
I’m ccing cabal-devel, as that list seems pertinent to this discussion too. In general I’m in favor of unifying efforts such as this.
For windows, I’d still like the _option_ to get prebuilt library binaries for the full platform db. The modularity means that they can be just downloaded in a separate folder now, rather than installed into e.g. the global db? If so, that’s a nice win. Here is my motivation — I tried the minghc installer and it mainly worked, but it played terribly with cygwin, which I use pervasively. So I found myself in a situation where one set of paths worked with cygwin, and the other set of paths let me build the network library. I still have some anxieties about those sorts of issues, and being able to “just download the binaries” would make me feel a bit safer about at least one workaround should things get too muddled up.
If we synchronize LTS and “platform libs,” then I would like A) some way of distinguishing “blessed platform libs” from “other libs in LTS” (to solve the “curation problem” which has always been a goal of the platform) and B) a standardized release schedule for LTS.
(And, of course, I assume this will _not_ be for the platform release upcoming, which is due very shortly, but we’ll have a longer lead time to integrate and shake out all the various issues and test, etc.)
On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote:
> *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
> - 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
> Libraries mailing list
> Libraries at haskell.org
More information about the ghc-devs