[opam 2.1~alpha3] Default/System switch invariant looks a little weak and performance heavy

[kit-ty-kate]

On a fresh install with ocaml 4.11.0 installed in /usr/local/bin:

$ opam init
[...]
$ opam switch
#   switch   compiler      description
->  default  ocaml.4.11.0  default

$ opam switch invariant
["ocaml" {>= "4.05.0"}]

Given usual switches will make their invariant using ocaml-base-compiler or ocaml-variants, I would expect system switches to make their invariant using ocaml-system to avoid completely changing compiler every time a new package with different constraints needs to be installed. Furthermore I wonder what's the performances of the solvers on this kind of switch.

I understand the intent of renaming the base switch from system to default (and thus changing its invariant), but I fear it might be too unstable and too slow for users.

For instance, if I create a separate system switch:

$ opam switch create system ocaml-system
[...]
$ opam switch invariant
["ocaml-system"]

and test the performances of the two switches:

$ opam switch default
$ time opam install --show-actions dune
[...]
opam install --show-actions dune  51.61s user 2.75s system 100% cpu 54.353 total

$ opam switch system
$ time opam install --show-actions dune
[...]
opam install --show-actions dune  30.37s user 2.57s system 100% cpu 32.940 total

[AltGr]

There are two concerns in your report: lack of constraints, and solver performance

Lack of constraints

I am not sure this is really an issue: upon switch creation, opam will choose the latest version available; and on requesting the installation of packages, it will only downgrade if there is no other solution, so the user will be faced with a proposal of downgrade instead of a conflict report. This seems slightly better ?

What's indeed a change is that the default config in opam 2.0 would cause opam init to choose the system compiler if that was recent enough, while 2.1, using this invariant, will choose the latest version available, which is unlikely to be the system compiler.

This means that opam init will be more likely to compile OCaml and take a longer time ; but you will be less likely to have to create a new switch at a different version right away? I am not sure of the most common uses here.

Solver performance

This is an issue that will happen anyway in many cases, so I still hope to be able to optimise enough that it becomes OK and would prefer to focus my efforts on that. If we can't get to more satisfying solving times, however, avoiding too lax solver invariants would be a preferred mitigation indeed.

I'll need to experiment again, but part of the edge of opam 2.0 is due to specific pre-processing done to the package universe, analysing the switch invariant and stripping all conflicting packages; this is more difficult to do in the case of generalised switch invariants and was dropped, but with some work we can still try this approach.

Another possibility, besides of course working on the solver backend itself, would be to add a layer of solving in the following way:

• check packages that are mentionned in the switch invariant, and lock them to their version (simulating 2.0 beheviour, and making the above simplifications possible again without additional work)
• check for the existence of a solution in this case (we can do that very fast)
  • if there is one, run the solver on this simplified universe
  • if not, call the solver normally, basically falling back to the current behaviour

This is not purely an optimisation, as it also means that opam will never change the installed "base packages" unless strictly necessary. In particular, opam upgrade won't propose an upgrade of your compiler when there is a new release (that all your installed packages are compatible with) (opam upgrade ocaml should still work though).
Maybe this is reasonable anyway ?