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.) —Gershom On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentcz...@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 > 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 > _______________________________________________ > Libraries mailing list > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
