<div dir="ltr">







I'm glad to read the variety of response, and want to summarize and respond to the most common points:<br><br><b>stack is too new </b>& <b>having two package managers will confuse</b><div>— It is indeed new, though it has arrived very well formed, and has gained a lot of users in short order.  There are two reasons why I think we should be including it (or rather, including the version a few months down the road when we do the next major HP):</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>1) It's approach to package db organization is very good,</div><div>2) I would be better for all that stack were part of the suite of tools, rather than an alternative suite.</div></blockquote><div>Too be clear: I don't anticipate stack replacing cabal - different tasks will need one or the other. But I would like to see them unified in package db management.<br><br><b>nix-like package management</b></div><div>—  I'll be honest: I don't think nix-style package management is all that useful. Enabling the package machinery to be able to support all those different package builds is fine. But it seems the devil is in the user experience of the tools that manage it. Until we see what use cases those tools support, I really have no way to evaluate what extending package dbs this way will add.<br><br><b>possible change to cabal sandbox handling of the global db</b></div><div>— Of course this will improve more complex builds for people who download the HP - but does so by reducing the HP install to a minimal install. This is fine, but I think what we proposed goes further.</div><div><br></div><div class="gmail_extra"><div><b>pre-built package binaries are good</b></div><div>— Yes, especially on Windows, but I'd like to see a way that users can get those binaries, easily, and securely, without bloating the HP download. At present, users have to download 150MB ~ 230MB of installer - it is heavy! If we can make it so that users only have to compile a package the first time they use it in any project, for many this is ideal: you start minimal, incur cost is only once on first use, and build exactly in your system environment. If we augment this with a "binary repository" then we can let users decide to trade the compile cost for the download cost.<br></div><div><br></div><div>- Mark</div><div><br></div><div>Sorry for slow, group response, I'm still on vacation!<br></div><div><br></div></div></div>