
Hi all, So, I was feeling a bit frustrated about the complexity of the Cabal sandbox code, and when I get frustrated I start deleting things... Just for funzies I tried deleting all the obvious non-sandbox code in cabal-install, and here's the result: https://github.com/BardurArantsson/cabal/commit/27aa116cc0ab3c824bd80c175ecb... As you can see it means the removal of 218 lines, but most importantly IMO it drastically simplifies the code in some places, notably loadConfigOrSandboxConfig (funnily enough) becomes trivial and classifyPackageEnvironment disappears (conincidence? I think not.). I'm sure there are quite a few other things that could also be removed. I've left a few notes sprinkled in the code marked by XXX. Obviously, this isn't mergeable as-is[1] and I mostly did it for a lark, but what do you guys think? Is this something that could/should be pursued further? I seem to recall hearing some rumblings that some people really wanted cabal-install to be sandbox-only. I think this little Proof of Concept shows that it would be beneficial at least from a code complexity/maintenance perspective. (I certainly know that I've been getting really frustrated trying to implement #2810 because the code is incredibly *gnarly* because it has to account for a lot of combinations of things, and this might be a good way to try to reverse the tide of option-itis.) Regards, /b [1] For one thing, there's need to be some sort of deprecation period of non-sandbox mode at the very least. :)

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...
-g
On Tue, Sep 8, 2015 at 1:16 PM, Bardur Arantsson
Hi all,
So, I was feeling a bit frustrated about the complexity of the Cabal sandbox code, and when I get frustrated I start deleting things...
Just for funzies I tried deleting all the obvious non-sandbox code in cabal-install, and here's the result:
https://github.com/BardurArantsson/cabal/commit/27aa116cc0ab3c824bd80c175ecb...
As you can see it means the removal of 218 lines, but most importantly IMO it drastically simplifies the code in some places, notably loadConfigOrSandboxConfig (funnily enough) becomes trivial and classifyPackageEnvironment disappears (conincidence? I think not.). I'm sure there are quite a few other things that could also be removed. I've left a few notes sprinkled in the code marked by XXX.
Obviously, this isn't mergeable as-is[1] and I mostly did it for a lark, but what do you guys think? Is this something that could/should be pursued further? I seem to recall hearing some rumblings that some people really wanted cabal-install to be sandbox-only. I think this little Proof of Concept shows that it would be beneficial at least from a code complexity/maintenance perspective.
(I certainly know that I've been getting really frustrated trying to implement #2810 because the code is incredibly *gnarly* because it has to account for a lot of combinations of things, and this might be a good way to try to reverse the tide of option-itis.)
Regards,
/b
[1] For one thing, there's need to be some sort of deprecation period of non-sandbox mode at the very least. :)
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

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? FWIW, I'd also be happy if sandboxes could be scrapped (as being unnecessary) rather than the other way round. The main point of this execercise was to show how much simpler things *could* be, if we really want them to. (I think cabal-install *needs* to become a lot simpler if it's to be in any way maintainable and extendable.) Regards,

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

On 09/09/2015 10:08 AM, Kosyrev Serge wrote:
Bardur Arantsson
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
Thanks for the pointer. Not sure how I missed that. Looks very promising -- I'll give it a whirl some time in the next few days. Regards,
participants (3)
-
Bardur Arantsson
-
Gershom B
-
Kosyrev Serge