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

Either implement implicit snapshots or have an option promoting everything to the local DB #3782

Closed
mgsloan opened this issue Jan 16, 2018 · 3 comments

Comments

@mgsloan
Copy link
Contributor

mgsloan commented Jan 16, 2018

To me, one of the ugliest bits of stack right now is if you want to build all of the packages in your build plan with a particular flag. To do it currently, you have to ensure that your snapshot and all packages that could potentially be shared are unregistered. Moreover, these global build settings can leak into snapshot packages.

I propose that for the next stack release that either implicit snapshots should be implemented (#3330), or if it isn't implemented yet, a simple approach should be implemented to make the semantics match what they will be with implicit snapshots:

  1. Snapshot packages that were configured with nonstandard settings should be unregistered and removed from the sharing cache.

  2. By default, if $everything: ... is specified, then promote the entire snapshot to the local DB. Similarly, ghc-options for a particular package should promote that package to the local DB.

The cost will be a lot less package sharing if $everything is specified in ghc-options. However, this will finally allow us to implement configure-options: + --configure-options with decent semantics, and make ghc-options: for more reasonable.

We could consider this change a nice step along the way to implicit snapshots, but it might be less work to just go ahead and do implicit snapshots and skip the intermediate step.

@borsboom
Copy link
Contributor

borsboom commented Apr 4, 2018

@mgsloan This doesn't look like it needs to block the next release. Can we downgrade the priority?

@snoyberg
Copy link
Contributor

snoyberg commented Apr 9, 2018

This will ultimately be subsumed by #3922. This is a big enough change to the codebase that we should definitely not be considering it for 1.7.

@snoyberg
Copy link
Contributor

Closing in favor of #3922.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants