-
Notifications
You must be signed in to change notification settings - Fork 699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do we want to encourage new users to use sandboxes? #6866
Comments
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. |
There is a ticket for adding readthedocs redirects to haskell.org/cabal, but I haven't got around to doing it yet. |
Oh wow, I'd never actually come across that |
@23Skidoo Could you please link to that ticket? I will go there and volunteer my services. |
The cabal 3.2 docs mention sandboxes prominently, but Also, the example commands use the |
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... |
@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). |
@fgaz; Which commands have a |
@tomjaguarpaw It's a global option, not a command option |
@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? |
The OP is fixed: the doc link mentioned there, @fgaz wrote:
Done, see #7587. This issue can be closed. |
Agreed. Thank you all. |
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:
Mention prominently in the "Developing with sandboxes" section that sandboxes are obsolete and new users should use Nix-style builds instead, or
Move all mention of sandboxes to a "obsolete behaviour only kept around for compatibility section", or
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.
The text was updated successfully, but these errors were encountered: