cabal-install rebooted?

[Gershom B]

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 <spam at scientician.net> wrote:
> 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/27aa116cc0ab3c824bd80c175ecbe51955dd9271
>
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel