Bardur Arantsson <s...@scientician.net> writes: > 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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
