Report that the opam version is 2.2.0 while solving

[gridbugs]

Certain packages require that the opam version be 2.2.0 or above, and the solver will refuse to include those packages with the current opam version baked into dune, which is 2.2.0~alpha-vendored.

[Alizter]

It seems wrong that we are allowing the solver to use this value at all. I'm not familiar with how this is meant to work. Don't we already check the opam version of a package when translating the build instructions, maybe we allow the solver to do its thing, ignoring the opam version, and then validate the version at a later step.

[Leonidas-from-XIV]

Which packages are doing that? To me it seems fairly odd that packages declare opam-version: 2.0 and then require a higher version of OPAM (what for?).

(This is not to say that depending on opam-libs >= 2.2.0 is wrong, but we presumably handle that correctly)

[gridbugs]

I ran into this issue with io-page-unix while working on moby/vpnkit#653.

[Leonidas-from-XIV]

I think this condition does not make sense in the context of Dune. Dune doesn't really have an "opam-version": we have a fork of a their solver but don't share the same feature set necessarily. The reason for this available constraint is that io-page-unix is deprecated and from how I understand that commit the support for the flag was added in opam 2.2, without bumping the opam-version: 2.0 stanza to opam-version: 2.2. But whether dune pkg supports deprecated or not has nothing to do with the version of our forked solver.

If we change the solver to the pubgrub-solver as we've been contemplating then there's no opam code left, what would our opam-version be in this case? Do we need to always track the current release of opam?

If we need it to preserve compatibility with that condition, we could set it to a really large integer or change the comparison function on this variable to always evaluate to true.

[gridbugs]

Agreed that this variable isn't super meaningful to dune. Either of your proposals sound reasonable to me as a long term solution. For the moment I'll still merge this since it solves the immediate problem with vpnkit.

[rgrinberg]

If we need it to preserve compatibility with that condition, we could set it to a really large integer or change the comparison function on this variable to always evaluate to true.

That doesn't always work either. Users can write upper bounds or negate the check.

I think what gridbugs is doing is the right thing. Pick some adhoc value that works with as many packages as possible.