[Haskell-cafe] is it normal for docs to be pending for 24 hours?

[Saurabh Nanda]

>
> Here's what I wrote last time this was discussed:
>
> https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124896.html
>
> 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.
>


I read that and
https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal 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?

One of the things that makes stack different from a Gemfile.lock is
probably the following (from
https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal):

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.


 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?

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.

Really hope to see a unified tool that everyone gets behind, instead of
diving effort and resources.

-- Saurabh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161114/8309e6aa/attachment.html>