-
Notifications
You must be signed in to change notification settings - Fork 843
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
Rebuilding packages from the global database with modified dependencies #4510
Comments
Could #4508 require the same fix? |
@dbaynard that one looks to be quite a different issue |
After some further discussion with @qrilka and a reminder that global packages may not match what's on Hackage, I have a different proposal: https://www.snoyman.com/blog/2019/01/mismatched-global-packages. |
It looks like we could have troubles going that way but correct me if there are any flaws in my logic: |
@qrilka I don't think this finding is anything new. Stackage already ensures that packages from the global database, or at least those which are transitive dependencies of |
I didn't know that there's a special check for that, I guess it needs to be added into the new curator? |
Yes, I guess so. I didn't think about that previously. |
This applies to Stack master, specifically commit 9900d99. Repro (on a non-Windows system). With the following
stack.yaml
:This replaces the global
time
package with a different version. Runningstack build unix
causes bothtime
andunix
to be compiled, which makes sense, sinceunix
depends ontime
.Running
stack build unix
a second time should be a no-op, but instead, it rebuilds:This appears to be because the
SourceMap
knows nothing aboutunix
(since it's a global package and not present at all in snapshot), and therefore Stack is ignoring the already-present copy in the snapshot database.Possible solution: update the SourceMap to contain information about global packages.
CC @qrilka
The text was updated successfully, but these errors were encountered: