Make revision for plutus-core

[phadej]

Reading cardano-node's cabal.project I noticed:

constraints:
  -- plutus-core: needs a constraint here, fixed on plutus master but not in the released version
  , algebraic-graphs < 0.7

Wouldn't it best for everyone to make the revision for plutus-core in cardano-haskell-packages then copying that constraint ~everywhere.

That applies to most of constraints in https://github.com/input-output-hk/cardano-node/blob/f7496b44538cf490eb6be9199783f37bad77862e/cabal.project#L85-L107
I'd expect those bounds to be corrected in the repository (with revisions).

EDIT: I'm very frustrated that I cannot just add the repository cardano-haskell-packages and use plutus-core or cardano-api, but I still need to add a bunch of constraints which are virtually impossible to discover reliably.

[michaelpj]

We very much plan to do this. Unfortunately revisions from CHaP don't get picked up in haskell.nix, so we wouldn't benefit properly from this until we fix that, which is why we haven't started yet.

[angerman]

This is indeed very annoying and the current practice of cargo-culting constraints is not optimal. What we do see with more recent package release to CHaP, that proper bounds are actually start to be introduced. Revisions would certainly help in the interim, and revisions are being addressed in input-output-hk/haskell.nix#1775. Thus we should be able to have this soon.

[andreabedini]

@michaelpj it’s actually worse in the sense that haskell.nix barf in presence of non-hackage revisions.

If haskell.nix just ignored them we could at least start collecting revisions into chap to save non-nix users. 😿😿😿

[angerman]

@michaelpj it’s actually worse in the sense that haskell.nix barf in presence of non-hackage revisions.

If haskell.nix just ignored them we could at least start collecting revisions into chap to save non-nix users. 😿😿😿

Well, we could initially just drop the barfing, no? I think the risk we'd be running is that haskell.nix based projects would work in the shell, but fail to work in CI.

[michaelpj]

Saving the non-nix users doesn't help us much since all our projects also build with Nix, so they'll need to cargo cult the constraints anyway 🤷

[phadej]

Saving the non-nix users doesn't help us much since all our projects also build

But there are also other consumers of e.g. plutus-core and cardano-api, which may not use haskell.nix. Making revisions would help them, and also you - in the long run - when haskell.nix is fixed.

Please start to pay attention to the other users of "cardano platform" libraries then just IOG.

[michaelpj]

We are paying attention, and we are doing things that help you, we're just doing them in the order that helps us the most also 🤷

[shlevy]

I believe haskell.nix supports this now, and we want a revision for plutus-core for the new cardano-crypto-class, so maybe we can combine this

[shlevy]

Actually I'm confused about what's happening here, as plutus-core has had algebraic-graphs >= 0.7 since August.

[shlevy]

https://github.com/input-output-hk/cardano-haskell-packages/pull/140 is open, not sure if there's something to add there to fix this issue as well.

[phadej]

The original issue was not about allowing new stuff, it's about disallowing dependencies packages don't work with. E.g. precise lower bounds would be a great start.

[andreabedini]

<3

[michaelpj]

I did a lot of such revisions recently, most of the constraints are now not needed.