Cabal: Do we want to encourage new users to use sandboxes?

[tomjaguarpaw]

I have the impression that sandboxes are obsolete and only supported (if at all) to grandfather in behaviour for existing users, and that new users should be using Nix-style builds by default. On the other hand, instructions regarding Developing with sandboxes are still prominently displayed in the official documentation. That led a new user to believe that they are still a "standard" way of using cabal.

Is there still a good reason to prefer sandboxes over Nix-style builds in new projects? If not perhaps we could do one of the following:

1. Mention prominently in the "Developing with sandboxes" section that sandboxes are obsolete and new users should use Nix-style builds instead, or

2. Move all mention of sandboxes to a "obsolete behaviour only kept around for compatibility section", or

3. Completely remove all mention of sandboxes from the official documentation

I'm happy to submit a documentation PR for whatever people think is the right approach.

[georgefst]

Very relevant: #6445. I didn't realise @phadej had actually gotten that far until I just checked, but seems like the right approach. Does mean the documentation improvements are even more urgent now.

[phadej]

https://cabal.readthedocs.io/en/latest/ doesn't mention sandboxes anymore.

I have no access to what we have on haskell.org site. I'd rather remove that in favor of readthedocs, as keeping latter up to date is task which no one is up for.

cc @m-renaud, @hvr, @23Skidoo

[23Skidoo]

There is a ticket for adding readthedocs redirects to haskell.org/cabal, but I haven't got around to doing it yet.

[georgefst]

Oh wow, I'd never actually come across that cabal.readthedocs page, and assumed that the version on haskell.org was the most up-to-date (I have now just noticed the very faint 3.0.0.0...). FWIW, search engines seem to strongly favour the latter, so I'm sure a lot of people would benefit from being redirected.

[tomjaguarpaw]

@23Skidoo Could you please link to that ticket? I will go there and volunteer my services.

[christian-oudard]

The cabal 3.2 docs mention sandboxes prominently, but cabal sandbox init won't run in version 3.2. https://cabal.readthedocs.io/en/3.2/installing-packages.html#sandboxes-basic-usage

Also, the example commands use the v2- prefixes, when they could just as easily be dropped.

[ivanperez-keera]

I always found sandboxes extremely convenient and never understood why they had to be discouraged, removed or a new style was absolutely needed. IMO sandboxes were an absolute game changer.

From what I see in the instructions for 3.2, installing with new versions will install in the user's home. I also see that v1-commands will be dropped (?). Is there any way in newer versions of cabal to replicate the behaviour of sandboxes, meaning that all packages are installed in the current directory and no changes occur outside that directory?

EDIT: 3 absolutes is too much...

[fgaz]

Is there any way in newer versions of cabal to replicate the behaviour of sandboxes, meaning that all packages are installed in the current directory and no changes occur outside that directory?

@ivanperez-keera If you really need that (I don't see why though) you could set --store-dir=./store so that your project has its personal store. Hackage sources, indices, and probably some temporary files would still end up outside it though (like with sandboxes I think).

[tomjaguarpaw]

@fgaz; Which commands have a --store-dir option? None of (v2-)install/build/repl do, at least according to --help on cabal 3.2.0.0.

[fgaz]

@tomjaguarpaw It's a global option, not a command option

[fgaz]

@tomjaguarpaw you're right... it doesn't show up in the global help nor in the command ones. It still works though. Could you open a ticket about that if there isn't one already?