Skip to content
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

Merged
merged 1 commit into from
May 6, 2020
Merged

Remove sandbox #6747

merged 1 commit into from
May 6, 2020

Conversation

phadej
Copy link
Collaborator

@phadej phadej commented May 1, 2020

No description provided.

@m-renaud
Copy link
Collaborator

m-renaud commented May 2, 2020

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?

@hvr
Copy link
Member

hvr commented May 3, 2020

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?

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.

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?

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...

If its the later, is there a guide we can point to for how to get off of sandboxes?

...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 sandbox workflow, and how to map the previously used cabal sandbox invocations to the new respective v2-build mechanisms...

@m-renaud
Copy link
Collaborator

m-renaud commented May 3, 2020

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
@phadej phadej marked this pull request as ready for review May 6, 2020 10:21
@jneira
Copy link
Member

jneira commented May 6, 2020

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.

@phadej
Copy link
Collaborator Author

phadej commented May 6, 2020

I'm locking discussion on this PR. Discuss issue on #6445

@haskell haskell locked as off-topic and limited conversation to collaborators May 6, 2020
@phadej phadej merged commit a6aa0bb into haskell:master May 6, 2020
@phadej phadej deleted the remove-sandbox branch May 6, 2020 13:49
@emilypi
Copy link
Member

emilypi commented May 10, 2020

🎉

@phadej phadej added this to the 3.4.0.0-rc1 milestone Jul 10, 2020
@andreasabel andreasabel added the re: sandbox Concerning sandboxes (removed in 3.4) label Oct 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
re: sandbox Concerning sandboxes (removed in 3.4)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants