*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
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.lentczner@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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
planning that it would happen after the first few releases. I'm fine with
doing it starting with the next release if that's desired.
The cygwin/msys conflict is a problematic one. stack has more flexibility
addressing this than MinGHC did, since stack can control the PATH more
directly. What we do now is, by default, add msys to the beginning of the
PATH, and provide a command line option to not use msys at all. I believe
this combination has addressed the bug reports we've received in the past.
That's not to say I'm opposed to generating binary databases; I'm actually
in favor of having that option for all platforms at some point (there's an
open stack issue about it[1]). But it's a significant amount of work, and I
think if possible we should defer it until we've figured out initial
integration points.
[1] https://github.com/commercialhaskell/stack/issues/117
On Sun, Jul 12, 2015 at 9:20 AM Gershom B
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
*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
On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner@gmail.com) wrote: 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
2015-07-12 18:03 GMT+02:00 Mark Lentczner
- [...] Haskell Platform becomes the standard way to get *GHC* and related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. [...]
What about haddock? I guess "GHC" implicitly means "haddock", too.
Apart from that +1, modulo some minor details which have already been mentioned.
Mark Lentczner 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.*
[..]
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.
Sounds great to me! Personally, I do not mind how the Haskell Platform achieves these goals; I will simply adapt to whatever tools the platform happens to install on my machine. Hopefully, they come with suitable documentation. For instance, one thing I don't understand about stack yet is in which location it "magically" installs GHC and packages, and how I can invoke `ghci` from these locations. Somehow, I was unable to understand this from the FAQ. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus
*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.*
[..]
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
db, users get the benefit of building and installing these common
only once per system, yet can easily bypass them for any given
Mark Lentczner wrote: package packages project if
desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work.
Sounds great to me! Personally, I do not mind how the Haskell Platform achieves these goals; I will simply adapt to whatever tools the platform happens to install on my machine.
Hopefully, they come with suitable documentation. For instance, one thing I don't understand about stack yet is in which location it "magically" installs GHC and packages, and how I can invoke `ghci` from these locations. Somehow, I was unable to understand this from the FAQ.
I think this FAQ entry should help[1] on the first question:
Note that stack setup installs GHC into ~/.stack/programs/$platform/ghc-$version/ and not a global location.
For the second question: either `stack ghci` or `stack exec ghci` should achieve what you're looking for. The former is a bit more experimental, and does more intelligent stuff at the project level as far as loading up your code. The latter simply runs the ghci command with appropriate PATH and GHC_PACKAGE_PATH environment variables set. [1] https://github.com/commercialhaskell/stack/wiki/FAQ#i-already-have-ghc-insta...
participants (5)
-
Gershom B -
Heinrich Apfelmus -
Mark Lentczner -
Michael Snoyman -
Sven Panne