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

Possible fix for #949 #996

Closed
wants to merge 2 commits into from
Closed

Possible fix for #949 #996

wants to merge 2 commits into from

Conversation

hamishmack
Copy link
Contributor

No description provided.

@hamishmack hamishmack force-pushed the hkm/fix-cardano-wallet branch from 08ff40e to 439970d Compare January 30, 2025 01:03
It depends on plutus-ledger, recent versions of which, are also disabled in the tests for GHC 8.10 (presumably because they also do not build).
@hamishmack
Copy link
Contributor Author

I'm not sure if disabling ghc 8.10 was actually necessary. Rebasing the changes onto the latest CHaP did seem to fix a lot of the failures.

@hamishmack
Copy link
Contributor Author

This looks like incompatible versions https://github.com/IntersectMBO/cardano-haskell-packages/actions/runs/13043668079/job/36390587302?pr=996#step:7:1164

Does something need updating?

@abailly
Copy link

abailly commented Jan 30, 2025

Thanks for looking at that @hamishmack Do I understand correctly I would need to rebase the PR on a recent CHaP?
Definitely can do that...

@abailly
Copy link

abailly commented Jan 30, 2025

Sorry, I don't understand where the problem comes from: is there a bound missing?

@abailly
Copy link

abailly commented Jan 30, 2025

This release is fairly recent, eg. 3 weeks old, and was explicitly made to be compatible with latest node releases

@abailly
Copy link

abailly commented Jan 30, 2025

OK, I think I understand: The bounds are set in the cabal.project hence not available in the .cabal files, so when trying to build with "whatever" versions are available it has a high probability of failing 🤦

@abailly
Copy link

abailly commented Jan 30, 2025

Is that correct?

@hamishmack
Copy link
Contributor Author

Yes that looks like the problem. These constraints here:

constraints:
    base >= 4.18.2.0 && < 5

  , bech32 >= 1.1.7

  -- Cardano Node dependencies:
  , io-classes >= 1.4
  , io-classes -asserts

  , ouroboros-consensus-cardano ^>= 0.18
  , ouroboros-network ^>= 0.16.1
  , ouroboros-network-protocols ^>= 0.9

Are not visible to CHaP and it is testing the packages without them. You can see the dependencies picked on line 293 of the log. They include things like --dependency=ouroboros-consensus-cardano=ouroboros-consensus-cardano-0.21.0.0-2dmx1khfGo51sXXs7f9J0w (instead of 0.18).

The best solution is probably to move those constraints from the cabal.project into the .cabal files and make a new PR.

I suspect you might still need to use the trick in this PR to disable testing with GHC 8.10.

@hamishmack hamishmack closed this Jan 30, 2025
@abailly
Copy link

abailly commented Jan 31, 2025

That makes sense. I completely forgot about those bounds, and the fact they were set at cabal.project level and not individual .cabal files which obviously is problematic when one wants to publish individual libraries 😅
As for the 8.10.7 test execution issue, we could just bypass it the same way: Add a condition in the cabal file?

@hamishmack
Copy link
Contributor Author

Add a condition in the cabal file?

Unfortunately I think CHaP does not know to look for buildable in the .cabal file and it might still try to build it (and fail at the planning stage).

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

Successfully merging this pull request may close these issues.

2 participants