Rewrite the conflict explanation extraction mechanism

[AltGr]

Finally! This needs more testing, so please everyone gather your
extreme conflict messages and send them to me; but this is very
promising.

[kit-ty-kate]

Really amazing! I tried it quickly locally and I have a few comments.

Before:

$ opam install extlib-compat
The following dependencies couldn't be met:
  - ocaml-variants → ocaml = 4.11.0
  - extlib-compat → ocaml < 4.07.0 → ocaml-variants < 4.06.2~
      incompatible with the switch invariant ["ocaml-variants" {= "4.11.0+trunk"}] (use `--update-invariant' to force)
  - extlib-compat → ocaml < 4.07.0 → ocaml-base-compiler (>= 3.07+2 & != 3.09.2 & != 3.10.2 & != 4.01.0 & != 4.02.2 & != 4.04.1 & != 4.06.0 & < 4.07.0)
      conflict with the base packages of this switch
Your request can't be satisfied:
  - No available version of ocaml satisfies the constraints
  - No available version of ocaml-variants satisfies the constraints
  - ocaml-variants (!= 4.00.1+BER & != 4.03.0+beta1+flambda & < 4.03.0+statistical-memprof | >= 4.04.0+BER & != 4.05.0+beta3 & < 4.06.0+32bit) is in conflict with ocaml-base-compiler

No solution found, exiting

After:

$ opam install extlib-compat
[ERROR] Package conflict!
  * No agreement on the version of ocaml:
    - (invariant) → ocaml-variants = 4.11.0+trunk → ocaml = 4.11.0
    - extlib-compat → ocaml < 4.07.0
    You can temporarily relax the switch invariant with `--update-invariant'
  * No agreement on the version of ocaml-variants:
    - (invariant) → ocaml-variants = 4.11.0+trunk
    - extlib-compat → ocaml < 4.05.0 → ocaml-variants < 3.09.2~
    You can temporarily relax the switch invariant with `--update-invariant'

No solution found, exiting

I feel like the second bullet point could be removed for an even shorter conflict message. However I suppose this might be needed for much difficult constraints.

I'm also not sure this is a good idea to tell users about --update-invariant. What about:

You might want to use another switch or update your current switch invariant.

or something like that? I'm not sure what would be the best sentence here but I'm sure we can find something.
In particular I don't think users using the "one version of the compiler per switch" scheme need that. I think most users will continue to use this and maybe some will have a default switch, however this one is already vague enough so --update-invariant wouldn't be necessary.

I also think this could be said only once as supposed to twice.

[kit-ty-kate]

Related issue: #4171

[samoht]

what does it mean? :-)

[AltGr]

The message is off, but there is actually little we can easily do about it :/ ; my opinion is that in this case the error is clear anyway so it's still OK (but yeah, we should at least filter out duplicate lines).

As for the explanation why, this is a different instance of #2229: we are working on a package graph where we can't really distinguish between conjunction and disjunction between edges. In this case, we have core<112.17.00 & core>112.17.00, which actually resolves to false, but without knowing about the & we wrongly reduce it as an |, which reduces to core != 112.17.00.
I'll check if I can find a way to detect such cases, and skip the "formula reduction" when they happen.

[samoht]

ha yes I was talking about the duplication -- but you are right, it's a bit hard to suggest something more actionnable to the user here.

[AltGr]

I feel like the second bullet point could be removed for an even shorter conflict message. However I suppose this might be needed for much difficult constraints.

I totally agree... but I couldn't find a generic way to determine that the first message is strictly better and supersedes the second... I already have quite a few heuristics to remove (lots of) spurious or secondary messages, but here the reason why the first is better is not totally clear, especially without resorting to independent knowledge of the package graph. We have a similar case here, where actually the "missing dependency" is extra information too.

In your case, there is another message issue though: a ocaml-variants < 3.09.2~ is appearing; this one would require some work, basically when no package version matches a constraint after conversion to cudf, we encode it as less than min existing version (this was raised in #4344 as well). I need to check if we can find a way to cure this.

I'm also not sure this is a good idea to tell users about --update-invariant

Indeed, it might help if you're stuck but may not be the best advice in general. I at least removed the duplication, but am open to removing or changing the message as well (with your suggestion, unless something better comes up ?)

Thanks!