Publish 1.4.0.0 for plutus core packages

[zliu41]

No description provided.

[michaelpj]

Alright, this is a real failure from the new CI, hooray. We need to deal with obsidiansystems/dependent-sum-template#9 now in a way that works for downstream without requiring config. See https://github.com/input-output-hk/plutus/blob/master/cabal.project#L57

[effectfully]

Alright, this is a real failure from the new CI, hooray. We need to deal with obsidiansystems/dependent-sum-template#9 now in a way that works for downstream without requiring config.

deriveGEq was removed and I guess we could just drop deriveGCompare . It would be very annoying for some of our users, since we added it because there was a request, not due to us needing it, but if it's a serious trouble, we could make that sacrifice. Alternatively, we could implement the GCompare instance ourselves, but that's a ton of boilerplate, but maybe we could think on a clever approach.

[michaelpj]

The alternative is just to add a spurious dep on dependent-sum so we can enforce the correct lower bound.

[andreabedini]

I want to understand why we are not picking a more recent dependent-sum here. On my machine, I removed the constraint from cabal.project and cabal picked dependent-sum-0.7.1.0 🤔

EDIT: I think I have figured it out.

As the failure above shows, in isolation, plutus-core-1.4.0.0 will get a build plan with dependent-sum-0.6.2.0 which has a bug. If I constrain the plan to include dependent-sum-0.7.2.0 instead, this is what changes:

# with --constraint="dependent-sum>=0.7.1.0"

-constraints-extras-0.3.2.1 lib
+constraints-extras-0.4.0.0 lib
-constraints-extras-0.3.2.1 exe:readme
+constraints-extras-0.4.0.0 exe:readme
-dependent-sum-0.6.2.0 lib
+dependent-sum-0.7.2.0 lib
-some-1.0.5 lib
+some-1.0.4.1 lib

The package some goes back! Why does that happen? It turns out that dependent-sum-0.7.2.0 has a constraint some >= 1.0.4 && < 1.0.5, and cabal would prefer to have a newer some (which is a direct depdendency of plutus-core) to have a newer dependent-sum (which is a transitive dependency).

Relaxing dependent-sum bound on some, I indeed get a plan with dependent-sum-0.7.2.0

# with --allow-newer=dependent-sum:some

-constraints-extras-0.3.2.1 lib
+constraints-extras-0.4.0.0 lib
-constraints-extras-0.3.2.1 exe:readme
+constraints-extras-0.4.0.0 exe:readme
-dependent-sum-0.6.2.0 lib
+dependent-sum-0.7.2.0 lib

This perhaps could be fixed with a revision on Hackage, but dependent-sum.cabal suggests that the situation is some subtle:

  reexported-modules:   Data.GADT.Compare,
                        Data.GADT.Show,
                        Data.Some
  -- tight bounds, so re-exported API is versioned properly.
  build-depends:        some >= 1.0.4 && < 1.0.5

The reexported packages are indeed from some. Now, I only had one coffee so I am not sure if this is the right thing to do but ... rejoice!

Adding the bound some <1.0.5 to plutus-core.cabal fixes the problem! Cabal is forced to pick an older version of some which is now compatible with a newer version of depedent-sum so we get the some result of --constraint="dependent-sum>=0.7.1.0" 🎉

EDIT 2: The reason we get dependent-sum-0.7.1.0 in the project without the constraint is because some-1.0.5 has been published on 2023-03-15T09:33:16Z while our hackage index-state if 2022-11-15T00:00:00Z. Therefore we exclude it anyway.