<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">Here's what I wrote last time this was discussed:<br>
    <br>
<a class="gmail-m_-6455336524766467003moz-txt-link-freetext" href="https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124896.html" target="_blank">https://mail.haskell.org/<wbr>pipermail/haskell-cafe/2016-<wbr>September/124896.html</a><br>
    <br>
    which is pretty much what Snoyman said in his follow-up here.  To
    me, stack is trying to solve the same problems as hsenv, as well as
    the same problems as cabal-install, as well as some problems that
    neither solves.  And although there's overlap between cabal-install
    and stack, that's not the same as saying there's overlap between
    stack.yaml and .cabal files.</div></blockquote><div><br></div><div><br></div><div>I read that and <a href="https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal">https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal</a> as well. Comparing to the Ruby world, would it be fair to say stack is analogous to rvm (or rbenv) and cabal is analogous to rubygems?</div><div><br></div><div>One of the things that makes stack different from a Gemfile.lock is probably the following (from <a href="https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal">https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal</a>):</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's also a black box which depends on three pieces of global, mutable, implicit state: the compiler and versions of system libraries on your system, the Cabal packages installed in GHC’s package database, and the package metadata du jour downloaded from Hackage (via cabal update). Running cabal install at different times can lead to wildly different install plans, without giving any good reason to the user.</blockquote><div><br></div><div> Basically the LTS. If you're using the same LTS resolver+OS, you'll get the same set of dependent packages every single time, right?</div><div><br></div><div>Still pressing this further, is there really no way to wrap dependency management (cabal) and environment management (stack) in a single UI? Although that's lesser of a problem than the hackage/stackage divide.</div><div><br></div><div>Really hope to see a unified tool that everyone gets behind, instead of diving effort and resources.</div><div><br></div><div>-- Saurabh.</div></div>
</div></div>