-
Notifications
You must be signed in to change notification settings - Fork 701
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
Remove sandbox #6747
Remove sandbox #6747
Conversation
One thought: there likely exists some users who still require sandbox functionality, if we remove support in future versions of cabal should we have a process for backporting bugfixes to previous versions of cabal that still support sandboxes? Or are we just saying: if you want bugfixes and new features, you need to figure out how to migrate off of the sandbox functionality? If its the later, is there a guide we can point to for how to get off of sandboxes? |
I don't think that's realistic given the current available resources. Our support model is currently to have people install the most recent stable release of cabal and we try hard to support a wide range of GHC releases with the most recent releases. Even backporting a fix to previous releases of cabal requires a non-neglibile amount of cognitive overhead which we just don't have the luxury for right now.
Yeah, as frustrating as this may come across to the affected parties, that's the state of affairs. And we do want to make it as easy as reasonable to migrate away from this legacy feature...
...I'm not aware of such a guide (maybe there exists one already though). Are you interested to write such a migration guide (I guess it'd be a small chapter/section in the cabal user guide)? In its simplest form it's just describing the basic legacy |
Yeah, that all makes sense and sounds reasonable. I guess one thing that could be useful to do is put out a pre-announcement on the main channels (mailing list, reddit, twitter, etc) to see if anyone is critically relying on this behaviour, and if there's enough response we could invest some time in putting together a migration guide, otherwise it may not be worth the time if there's only a handful of users. |
Removes command and cleanups cabal-testsuite. The tests for haskell#3199 haskell#4099 haskell#3436 are removed, but they seem to be sandbox specific issues. Removes Sandbox.Types, Sandbox.Index and Sandbox.Timestamp modules. The Sandbox and Sandbox.PackageEnvironment are still there as some configuration in v1-commands happens through them (~/.cabal/config vs ./cabal.config). BuildExFlags contained only sandbox specific parameter, so it's removed as well. Remove sandbox support from cabal-testsuite Remove sandbox from GlobalFlags and Sandbox unit-tests
I am happy using v2 commands but i think this feature had been useful for lot of users for years so i agree with @m-renaud in it deserves a careful announcement in all possible channels. |
I'm locking discussion on this PR. Discuss issue on #6445 |
🎉 |
No description provided.