Investigate porting to use cabal new-build

[tmcgilchrist]

Since mafia is supposed to be a thin wrapper around cabal, it would make sense to see if we can switch over to using cabal new-build and friends.

[hvr]

@tmcgilchrist @erikd As mentioned in haskell/cabal#6445 we'd like to finally start removing legacy codepaths from cabal's code-base which are standing in the way. Do you envision updating/reengineering Mafia to work with the new cabal 3.x nix-style interface? Is there any ETA?

[erikd]

Mafia is still quite strongly tied to cabal-2.X. I seem to remember me having a bit of a go at 3.0 support when 3.0 first came out (and I seem to remember @tmcgilchrist also did some work), but I have since switched to just using cabal directly.

If there is any future to mafia, I think it would be to become an even thinner wrapper around cabal than it is even now. That would strip out the current sandbox usage, and probably make it less dependent on particular features of cabal.

[tmcgilchrist]

The latest Cabal we support is 2.4, I personally haven't updated to anything more recent than that for my workflows. @erikd is right the roots of mafia are tied to early Cabal 2.* and a large rewrite would be required to support 3.0 and beyond. I'm not familiar with the replacements for sandboxes in Cabal 3.0, I need to do further reading. How do they work to isolate dependencies between different projects and build flags eg. profiling builds.

Fwiw, while I haven't used Mafia myself, I believe it should be possible to emulate most of cabal sandbox-like workflows atop of cabal v2-build by orchestrating cabal accordingly and controlling the paths where it stores things. I'm happy to help brainstorm w/ the Mafia devs how to do this if they can elaborate on Mafia's requirements and what operations it needs to effect on a cabal project. @hvr

Mafia was build with a certain workflow of supporting local git submodules as dependencies, having a reproducible build (within reason) via lock files and a number of convenience features like per-project hoogle database, repl and isolated profiling builds. If these are achievable without sandboxes then we could move forward to using 3.0.

Just thinking on it, would you see that it is possible to support older sandbox versions of Cabal and the newer style 3.0? @hvr

There is some cross over in motivations with https://github.com/ocamllabs/duniverse

[hvr]

@tmcgilchrist I believe it would help for the further discussion if you could get yourself familiar with workflow that became the primary UI of cabal 3.x
(and it sounds like @erikd might already have experience with both Mafia and Cabal nix-style builds; maybe he can help provide insights too)

https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html offers a quick intro

The interesting flags you can use to achieve a higher degree of isolation than nix-style builds already perform are --builddir (defaults currently to dist-newstyle) and --store-dir (defaults to whatever has been configured in ~/.cabal/config; usually ~/.cabal/store/)