Use 0install solver #399
Use 0install solver #399
Conversation
opam-ci-check/lib/opam_build.ml
Outdated
| @@ -122,10 +115,9 @@ let setup_repository ?(local=false) ~variant ~for_docker ~opam_version () = | |||
| Otherwise the "opam pin" after the "opam repository set-url" will fail (cannot find the new package for some reason) *) | |||
| run "%s -f %s/bin/opam-%s %s/bin/opam" ln prefix opam_version_str prefix :: | |||
| run ~network "opam init --reinit%s -ni" opamrc :: (* TODO: Remove ~network when https://github.com/ocurrent/ocaml-dockerfile/pull/132 is merged *) | |||
| run "uname -rs && opam exec -- ocaml -version && opam --version" :: | |||
| run "opam option solver=builtin-0install && opam config report" :: | |||
There was a problem hiding this comment.
We tried enabling this in tests before, in #351, which produced the regression in #352
The problem was the tests on earlier opam versions:
Lines 156 to 159 in e682604
The conclusion we reached at that time was
the only place where not already using the dev version is the place where we explicitly wanted to be testing older opam versions. I think this means the change in #351 should just be reverted, because I think we cannot step testing on 2.0 - 2.1 until they are no longer used by the main distros.
There may be some other useful context there, and also in #354 .
AFACT, there is nothing in this change that will avoid the problems with hit with opam 2.2, or am I missing something?
This makes me wonder if the solver timeouts may be a reason for us to try to accelerate ocurrent/docker-base-images#132 and/or (at last) drop support for opam 2.0 and 2.1 in opam-ci.
I know we have wanted to keep testing on opam versions so long as they are in the repos of maintained distros, but if the quality of the tests are degrading across the board as a result (due to limit in opam's solver), I think it may be counter productive. This just follows your compelling logic here, I think.
WDYT?
mtelvers
force-pushed
the
solver-timeout
branch
from
7e44a7f to
0442e06
Compare
| @@ -122,10 +115,9 @@ let setup_repository ?(local=false) ~variant ~for_docker ~opam_version () = | |||
| Otherwise the "opam pin" after the "opam repository set-url" will fail (cannot find the new package for some reason) *) | |||
| run "%s -f %s/bin/opam-%s %s/bin/opam" ln prefix opam_version_str prefix :: | |||
| run ~network "opam init --reinit%s -ni" opamrc :: (* TODO: Remove ~network when https://github.com/ocurrent/ocaml-dockerfile/pull/132 is merged *) | |||
| run "uname -rs && opam exec -- ocaml -version && opam --version" :: | |||
| run "%sopam config report" (match opam_version with `V2_1 | `V2_2 | `V2_3 | `Dev -> "opam option solver=builtin-0install && " | `V2_0 -> "") :: | |||
There was a problem hiding this comment.
I'm assuming this implies you've tested to confirm that this works on opam 2.1!
There was a problem hiding this comment.
Yes, opam 2.1 onwards supports opam option, and 0install is already enabled at compile time.
We continue to see solver timeouts as reported by @mseri and collated here. This PR changes the default solver from mccs to 0install, which is the plan for future versions of opam.
I initially tried increasing the timeout again from 1000 to 1500, but even this was not long enough in some cases.
I have previously argued against changing the solver as this would make the CI differ from the user experience. However, users must already be mitigating this, as I do not expect they are waiting more than 25 minutes for a solution. The default timeout is 60 seconds!
Since opam-repo-ci is testing the instability of the package, maintainers will likely be ignoring cases where the solver times out. Therefore, it would be more useful to get results than fail on the timeout. Furthermore, this should speed things along as the 0install is much faster.