Bardur Arantsson
On 09/09/2015 12:22 AM, Gershom B wrote:
That _does_ look simpler!
However, I think there are multiple efforts underway towards the nix-style stuff. We had a GSoC on that for example. And in that workflow, if it all works out properly, then we end up with a situation where since the general-user-db has no conflicts, then sandboxes are the tools that become generally not required.
So I would be quite hesitant about moving things in the other direction...
I do see some advantages to having sandboxes still, namely isolation of the binaries into a single directory that you can put into $PATH, but I'm assuming/hoping there's some way to handle that in nix-style cabal/cabal-install as well. (If that turns out to be wrong, I imagine a middle-of-the-road approach here would be to just have a single package database and treat it as a simple cache of all the binaries ever compiled and we could still keep sandboxing for binaries and such..That might also nicely solve the problem of redudant compilation which happens with sandboxes now.)
Just out of curiousity, when is the GSoC deadline?
Success was recently announced: https://www.mail-archive.com/cabal-devel%40haskell.org/msg10091.html Excerpts: ,---- | Cabal should never tell you it can't install a package because some | reinstalls would be necessary. `---- ,---- | Try building things without a sandbox and see what happens! | (When I test, I've tried installing multiple version of Yesod | at the same time.) `---- -- с уважениeм / respectfully, Косырев Серёга -- “And those who were seen dancing were thought to be insane by those who could not hear the music.” – Friedrich Wilhelm Nietzsche