Override version equality constraints about cabal

[philderbeast]

I'm the author of Updo. While Updo can work by taking resolvers straight from stackage, having to download a stackage resolver's cabal.config manually and then edit it when there is a version conflict is probably the biggest ask of users of that tool. This is the last step, the "Fixup Unsatisfiable Version Constraints" step in introducing Updo to a project.

[phadej]

Few counterpoints:

• constraints are not only version constraints, e.g. also flags and these are very useful to local packages. And maybe eventually we get more types of constraints.

  • related: we need to solve for local packages's automatic flags

• Having equality constraints is not the only way to specify a "snapshot". Having a bunch of ^>= constraints is a viable option, which I prefer using. I like such "soft" snapshots: they barely ever break, but I do get new minor versions in.

• And again, having (manual) flags specified in a snapshot is actually a MUST, but these may need to be override for snapshots (and this applies to Stackage snapshots).

[ulysses4ever]

Great! And we can finally close #7556, I assume.

[philderbeast]

Perhaps the scope of this enhancement should grow to have == x.y.z versions override installed versions?

[andreabedini]

I think we should be able to address the problem of "overriding a package version while using a stackage snapshot" in a different way, and IMHO more principled.
Rather than introducing a "override" semantic to constraints:, the right thing to do would be to pick some packages and solve the rest. I am not sure about the effort required to implement this but it should at least be assessed before extending constraints:.

PS: I think this is basically how extra-packages: works. I need to check.

[andreabedini]

I think that it could work if constraints: didn't apply to project local packages. Which is something that could make sense independently since project local packages are fixed. Unfortunately the implementation seems to use constraints for everything (including specifying that the local package "pkg-a" has to come from "./pkg-a.cabal").

Just off the top of my head, maybe rather than solving for the targets we could solve only for the targets dependencies? this would leave project local packages alone. 🤷

[gbaz]

The reason I think that having overridable constraints is important is because it does not just solve the problem of overriding a package version while using a stackage snapshot but it solves many possible problems. And, if done correctly, not just making constraints able to be overridden, but anything in a cabal.project file, does so uniformly. So in that sense I think it is the clear and principled solution.

As soon as we have package imports and conditionals, we hit the issue -- we want to import something that sets a bunch of stuff, but we need to change it slightly. Either we clone it, or we allow overrides.

Similarly, suppose we have a fixed project file, but then we want to override that with something specific that's likely to mutate more often than our project -- for example a companywide configuration banning certain package versions that are known bad.

Then we need to allow our own settings to be overridden.

And as noted in a linked ticket, this holds not just for constraints, not just for flags, but also for e.g. index-state, or perhaps settings that should exist only in CI configurations but nowhere else, etc.

So making constraints and also all other settings overridable in a uniform way -- e.g. "last one wins" -- is a very straightforward approach to allowing all that.

Note that "pick some packages and solve the rest" is a form of override by the way, just a very specifically constrained and ad-hoc one.