Remove sandbox functionality

[phadej]

Related is e.g. #6444 (comment)

Maybe it's still a bit too early to remove v1-build, but sandboxes could IMHO be removed. If someone really needs them, they can be simulated.

Yet we need to do some cleanup, as v2-build is the default now.

[CMCDragonkai]

Just a question. In my Gitlab CI/CD I used .cabal-sandbox as the CI cache. Now if sandboxes are removed or I switch over to V2 commands. What is the appropriate thing to cache to speed up CI builds? Is it .cabal/store?

[phadej]

@CMCDragonkai yes. And .cabal/packages, when you clean a bit from there. See e.g. https://github.com/haskell-CI/haskell-ci/blob/f3e046c5ba5ba252ae44f82b2ecfb1e2d8760c0a/.travis.yml#L17-L31

EDIT: so packages .tar.gz aren't downloaded, also there's 01-index.tar.gz which would speed-up cabal update, as only delta is downloaded (and no need to cache quickly rebuildable stuff).

[Mistuke]

Maybe it's still a bit too early to remove v1-build, but sandboxes could IMHO be removed. If someone really needs them, they can be simulated.

How? :) I still use them to reproduce GHC issues people submit so I don't mess up my global config but genuinely unsure how to simulate them. The biggest thing I use them for is to have a package-db with all the dependencies of the repro the user submitted.

Since I often repro with ghc development builds I have to run with --allow-newer so I don't want these packages in my global store-dir as as soon as the ghc version changes I gotta rebuild again anyway (and the space isn't cleaned up automatically).

But new-install 's dist folder only contains a package-db with the package only, not it's dependencies.. so I end up having to use --store-dir to point it locally and then use two package-dbs where sandbox just has one so it's easier to use.

[hasufell]

Sandboxes are still used by some users and are very robust. Recovering from problems/failure is easy, while with v2-build, it basically boils down to removing the entire store. Semi-reproducible bugs like #6483 are a good example

[phadej]

My opinion is: people who need sandboxes could keep using old cabal-install versions. The less code there is blocking new development work, the better.

[hasufell]

The less code there is blocking new development work, the better.

I think that's a little quick. In case the code is really a problem, there should at least be a call for maintainers picking that up. We should know clearly whether there is no interest in this feature or not.

[Mistuke]

My opinion is: people who need sandboxes could keep using old cabal-install versions. The less code there is blocking new development work, the better.

I could.. If new GHC didn't often require bleeding edge Cabal.

[Mistuke]

In any case, whatever you guys decide as maintainers I'll live with :) especially if it's getting in the way of new things.

[hasufell]

Also note, you'll probably break tools like https://github.com/haskell-mafia/mafia when removing sandboxes.

[hvr]

Well, back in 2018 a ticket for "Investigate porting to use cabal new-build" was filed at haskell-mafia/mafia#240 -- but it doesn't seem like there has been much activity looking into how to adapt to cabal's announced v2-style UI. And I've got a hunch this isn't going to change unless there's a forcing function to do so.

So I'm for removing these cabal sandbox codepaths at last -- they're scheduled for removal anyway sooner or later (so the cost of migrating to a different mechanism will be incurred anyway); but delaying doing so translates into a maintainance/development cost for us, and consequently removing it sooner rather than later minimises the overall cost.

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.

[hasufell]

So there was no survey or announcement to figure out if sandboxes are still a feature the community wants?

[hvr]

We did have annoying warnings for all v1-* commands following a generic message-template in cabal 2.4 (released in 2018!) in order to raise some additional awareness (& discussions) that we did want to eventually decomission the v1-* commands, and to give people a chance to speak up...

$ /opt/cabal/2.4/bin/cabal sandbox 
Warning: The sandbox command is a part of the legacy v1 style of cabal usage.

Please switch to using either the new project style and the new-sandbox
command or the legacy v1-sandbox alias as new-style projects will become the
default in the next version of cabal-install. Please file a bug if you cannot
replicate a working v1- use case with the new-style commands.

For more information, see: https://wiki.haskell.org/Cabal/NewBuild

Moreover, the wording

For those who do not wish to use the new functionality, the classic project style will not be removed immediately, but these legacy commands will require the usage of the v1- prefix as of Cabal 3.0 and will be removed in a future release.

has been in the user guide since 2018 as well: https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html