-
Notifications
You must be signed in to change notification settings - Fork 232
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
index-state is not respected in the presence of revisions #2130
Comments
@pranaysashank Thanks for opening this. I had originally thought that you could have accidentally used a version of hackage.nix earlier than the index-state set in the project file, which would therefore be ineffective. Bumping hackage.nix could then cause the plan to change even without changing the project index-state. This does not seem to be the case.
For context, the revision fourmolu-0.14.1.0-r1 has been added on This is a bug, or quirk if you want to be extra diplomatic, in haskell.nix/modules/hackage-project.nix Lines 28 to 37 in 9cbdd6f
So haskell.nix is doing the equivalent of
This indeed produces the same plan (when using ghc-9.8.1). I think the end result is that the @hamishmack @angerman Is this something we want to fix? |
In the nix-diff in my comment above, the process package also gets rebuilt and even that has a new revision in the new index. So even dependencies are affected |
I find that more puzzling. You can see that, a part from fourmolu itself, the inputs to the plan derivations do not change.
and that in both cases we pass |
The plans always point to a Here's what I figured out, the packages in hackage.nix always have default revision set to the latest one and the plans pick the default revision. I made a change to hackage-db to extract the timestamp of the revision. This generates hackage packages to add a These changes to haskell.nix kronor-io@b057264 use the new Earlier I have noticed that updates to hackage.nix pin would sometimes even cause a rebuild of ghc, these changes fix those issues completely. Let me know if I a fix is desired and I should open a PR |
Describe the bug
When
index-state
orcabalProjectFile
is passed to haskell-nix.project or haskell-nix.tool, bumping the hackageSrc pin causes rebuilds because of new revisions in the new updated index.Steps To Reproduce
I have created a repo to reproduce the issue at https://github.com/pranaysashank/haskell-nix-index-state-bug-repro .
fOld
uses hackageNix with index-state2023-12-15T23:46:08Z
andfNew
uses a newer index state which contains the revisionsnix-build -A fOld --dry-run
nix-build -A fNew --dry-run
nix-diff
the.drv
forfourmolu
in both the runs, this shows the difference is because of the presence of new revisionsExpected behavior
Providing
cabalProjectFreeze
orindex-state
shouldn't cause rebuilds even in presence of revisions, this reduces the number of rebuilds we have to make when we want to update a dependency by bumping hackageSrc in the project.Additional context
it looks like @andreabedini has made recent changes w.r.t revisions and index-state (#1775) , perhaps you know more about the issue ?
x86_64-linux
oraarch64-darwin
): x86_64-linuxThe text was updated successfully, but these errors were encountered: