<div dir="ltr">Richard: The problem isn't the age itself, but rather the compatibility problems that age introduces. It can be quite difficult as a new user to get all of the libraries you want to use to play well with the platform. There's usually a way to make it work if you know what you're doing, but the platform is largely targeted at those who don't. This is particularly bad because library compatibility problems are inherently annoying to solve, or at least they feel that way to me.<div><br></div><div><br></div><div>I think Gershom framed the problem well. From the discussion, it sounds like there are a lot of potential solutions, mostly in the category of "re-conceive the platform".</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 9:32 AM, Miëtek Bak <span dir="ltr"><<a href="mailto:mietek@bak.io" target="_blank">mietek@bak.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-03-22, at 15:59, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>
<br>
> 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment.<br>
> 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions.<br>
<br>
<br>
</span><span class="">> I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals.<br>
<br>
</span>I’d be very happy to contribute to this effort.  In fact, I’ve already spent some of time addressing these issues.<br>
<br>
Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs — on OS X, and many Linux distributions.  FreeBSD and Windows are on the roadmap.<br>
<br>
Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time…) dependencies for Haskell programs.  They will be installed into a user-controlled directory, by wrapping around the native OS package manager.<br>
<br>
Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request:<br>
<a href="https://github.com/mietek/halcyon/issues/38" target="_blank">https://github.com/mietek/halcyon/issues/38</a><br>
<a href="https://github.com/haskell/cabal/issues/571" target="_blank">https://github.com/haskell/cabal/issues/571</a><br>
<br>
See the Haskell Language source code for an example:<br>
<a href="https://halcyon.sh/examples/#haskell-language" target="_blank">https://halcyon.sh/examples/#haskell-language</a><br>
<br>
See the Halcyon reference for details:<br>
<a href="https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages" target="_blank">https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages</a><br>
<a href="https://halcyon.sh/reference/#halcyon_extra_os_packages" target="_blank">https://halcyon.sh/reference/#halcyon_extra_os_packages</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Miëtek<br>
<a href="https://mietek.io" target="_blank">https://mietek.io</a><br>
<br>
<br>
</font></span><br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>