Open TheLortex opened 3 years ago
I have a proof of concept that is able to improve the quality of error messages by grouping identical messages together. It's actually a patch in opam-0install-solver
but opam-monorepo
will be the direct beneficiary of that. That results in very compact errors messages that contain all the same amount of information.
What do you think @NathanReb @Leonidas-from-XIV ?
An example, trying to lock mirage-dns
without the overlay repository:
- astring -> (problem)
No usable implementations:
astring.0.8.5: Doesn't build with dune
astring.0.8.4: Doesn't build with dune
astring.0.8.3: Doesn't build with dune
astring.0.8.2: Doesn't build with dune
astring.0.8.1: Doesn't build with dune
...
- dns -> (problem)
dns-lwt 1.1.3 requires = 1.1.3
Rejected candidates:
dns.1.0.1: Doesn't build with dune
dns.1.0.0: Doesn't build with dune
dns.0.20.1: Doesn't build with dune
dns.0.20.0: Doesn't build with dune
dns.0.19.1: Doesn't build with dune
...
- fmt -> (problem)
No usable implementations:
fmt.0.8.10: Doesn't build with dune
fmt.0.8.9: Doesn't build with dune
fmt.0.8.8: Doesn't build with dune
fmt.0.8.7: Doesn't build with dune
fmt.0.8.6: Doesn't build with dune
...
- mirage-device -> mirage-device.1.2.0
mirage-kv 2.0.0 requires >= 1.0.0 & < 2.0.0
- mirage-flow -> mirage-flow.1.6.0
mirage-protocols 3.1.0 requires >= 1.2.0 & < 2.0.0
- mirage-kv -> mirage-kv.2.0.0
mirage-kv-lwt 2.0.0 requires >= 2.0.0 & < 3.0.0
- mirage-net -> mirage-net.2.0.0
mirage-protocols 3.1.0 requires >= 2.0.0 & < 3.0.0
- mirage-protocols -> mirage-protocols.3.1.0
mirage-stack 1.4.0 requires >= 1.4.0 & < 4.0.0
- mirage-stack -> mirage-stack.1.4.0
mirage-stack-lwt 1.4.0 requires >= 1.3.0 & < 2.0.0
- mirage-time -> mirage-time.1.3.0
mirage-time-lwt 1.3.0 requires >= 1.0.0 & < 2.0.0
- num -> (problem)
Rejected candidates:
num.1.4: Doesn't build with dune
num.1.3: Doesn't build with dune
num.1.2: Doesn't build with dune
num.1.1: Doesn't build with dune
num.1.0: Doesn't build with dune
...
- ocaml -> ocaml.4.13.1
ocaml-base-compiler 4.13.1 requires = 4.13.1
- ocamlfind -> (problem)
No usable implementations:
ocamlfind.1.9.1: Doesn't build with dune
ocamlfind.1.8.1: Doesn't build with dune
ocamlfind.1.8.0: Doesn't build with dune
ocamlfind.1.7.3-1: Doesn't build with dune
ocamlfind.1.7.3: Doesn't build with dune
...
- astring -> (problem)
No usable implementations:
astring all versions: Doesn't build with dune
- dns -> (problem)
dns-lwt 1.1.3 requires = 1.1.3
Rejected candidates:
dns = 0.5.0 | >= 0.6.0 & < 1.1.0: Doesn't build with dune
dns >= 4.0.0: Incompatible with restriction: = 1.1.3
dns >= 1.1.0 & < 4.0.0: Requires cstruct >= 3.0.2 & < 6.0.0
dns = 0.5.1: Requires cstruct >= 0.5.1 & < 0.6.0
dns < 0.5.0: Requires cstruct >= 0.5.0 & < 0.6.0
- fmt -> (problem)
No usable implementations:
fmt all versions: Doesn't build with dune
- mirage-device -> mirage-device = 1.2.0
mirage-kv 2.0.0 requires >= 1.0.0 & < 2.0.0
- mirage-flow -> mirage-flow = 1.6.0
mirage-protocols 3.1.0 requires >= 1.2.0 & < 2.0.0
- mirage-kv -> mirage-kv = 2.0.0
mirage-kv-lwt 2.0.0 requires >= 2.0.0 & < 3.0.0
- mirage-net -> mirage-net = 2.0.0
mirage-protocols 3.1.0 requires >= 2.0.0 & < 3.0.0
- mirage-protocols -> mirage-protocols = 3.1.0
mirage-stack 1.4.0 requires >= 1.4.0 & < 4.0.0
- mirage-stack -> mirage-stack = 1.4.0
mirage-stack-lwt 1.4.0 requires >= 1.3.0 & < 2.0.0
- mirage-time -> mirage-time = 1.3.0
mirage-time-lwt 1.3.0 requires >= 1.0.0 & < 2.0.0
- num -> (problem)
Rejected candidates:
num >= 1.0: Doesn't build with dune
num < 1.0: Requires ocaml < 4.06.0
- ocaml -> ocaml = 4.13.1
ocaml-base-compiler 4.13.1 requires = 4.13.1
- ocamlfind -> (problem)
No usable implementations:
ocamlfind all versions: Doesn't build with dune
Compacting the information does look much nicer indeed! Thanks for working on this!
In particular, I assume this remove the annoying ...
ellipsis that sometime cut useful piece of information!
This definitely looks like a step in the right direction.
We haven't had time to look into error messages on our end but this is on the roadmap. I think something that could be done in opam-monorepo is to prioritize things a bit, e.g. by only showing a reduced set of "problems", selecting the ones that are most relevant to the user. It might be nice if you could expose parts of this in opam-0install-solver
, for example, it would probably be useful for us to re-use the code showing the condensed report for a single package/role.
Either way we'll always need a fallback when there's nothing obvious to show and so having a nicer full error report is very important.
@TheLortex were you able to submit a patch upstream for this?
opam-monorepo
has a very verbose error log when failing to solve packages. Its notably hard to distinguish the failing packages from the others.For the same set of dependencies, here are the outputs of
opam
andopam-monorepo
, where the failing packages are:mirage-kv
that has to be < 3.0.0 and >= 3.0.0uri < 1.9.4
,lwt < 3.0.0
, ... that require old versions of the ocaml compileropam
opam-monorepo