Bug: compatibility issue of learn-ocaml@master with latest version of deps in a fresh switch (without `--locked`)

[erikmd]

Bug description

FYI I've done several experiments with both (make && make opaminstall, docker build) build strategies, relying (or not) on the --locked option of opam install, and here is the issue:

• Creating a fresh opam switch with OCaml 4.12 with rm -fr _opam && opam switch create --deps-only -j 2 . (without --locked)
• Building learn-ocaml@master with make && make opaminstall && learn-ocaml build serve --repo=demo-repository
• Loading a demo exercise with firefox "http://localhost:8080/exercises/demo/#tab=text&prelude=shown"
• Then I get: Toplevel bytecode executable corrupt

Expected behavior

It can be noted that with a mere Docker command:

cd learn-ocaml && docker run --pull --rm -it -p 8080:8080 -v "$PWD/demo-repository:/repository" ocamlsf/learn-ocaml:master

the exercise loads smoothly and works very well with an OCaml 4.12 toplevel.

So this discrepancy may come from the fact the Dockerfile relies on the --locked flavor of opam install 😄

Additional context

FTR, here is the dump of the opam dependencies obtained in a fresh local opam switch, that reproduce the issue:

opam export deps_failure.txt

opam-version: "2.0"
compiler: ["ocaml.4.12.0"]
roots: ["ocaml.4.12.0"]
installed: [
  "angstrom.0.15.0"
  "asak.0.3"
  "astring.0.8.5"
  "base.v0.14.1"
  "base-bigarray.base"
  "base-bytes.base"
  "base-threads.base"
  "base-unix.base"
  "base64.3.5.0"
  "bigarray-compat.1.0.0"
  "bigstringaf.0.8.0"
  "biniou.1.2.1"
  "checkseum.0.3.2"
  "cmdliner.1.0.4"
  "cohttp.4.0.0"
  "cohttp-lwt.4.0.0"
  "cohttp-lwt-unix.4.0.0"
  "conduit.1.3.0"
  "conduit-lwt.1.3.0"
  "conduit-lwt-unix.1.3.0"
  "conf-git.1.1"
  "conf-libssl.3"
  "conf-pkg-config.2"
  "conf-which.1"
  "cppo.1.6.7"
  "csexp.1.5.1"
  "cstruct.5.2.0"
  "decompress.0.8.1"
  "digestif.1.0.1"
  "dune.2.9.1"
  "dune-configurator.2.9.1"
  "easy-format.1.3.2"
  "eqaf.0.8"
  "ezjsonm.1.2.0"
  "fieldslib.v0.14.0"
  "fmt.0.8.9"
  "fpath.0.7.3"
  "gg.0.9.3"
  "hex.1.4.0"
  "ipaddr.2.8.0"
  "jbuilder.1.0+beta20.2"
  "js_of_ocaml.3.10.0"
  "js_of_ocaml-compiler.3.10.0"
  "js_of_ocaml-lwt.3.10.0"
  "js_of_ocaml-ppx.3.10.0"
  "js_of_ocaml-toplevel.3.10.0"
  "js_of_ocaml-tyxml.3.10.0"
  "jsonm.1.0.1"
  "logs.0.7.0"
  "lwt.5.4.2"
  "lwt_react.1.1.4"
  "lwt_ssl.1.1.3"
  "magic-mime.1.2.0"
  "markup.1.0.2"
  "markup-lwt.0.5.0"
  "menhir.20210419"
  "menhirLib.20210419"
  "menhirSdk.20210419"
  "mmap.1.1.0"
  "num.1.4"
  "ocaml.4.12.0"
  "ocaml-base-compiler.4.12.0"
  "ocaml-compiler-libs.v0.12.4"
  "ocaml-config.2"
  "ocaml-migrate-parsetree.1.8.0"
  "ocaml-options-vanilla.1"
  "ocaml-syntax-shims.1.0.0"
  "ocamlbuild.0.14.0"
  "ocamlfind.1.9.1"
  "ocp-indent-nlfork.1.5.4"
  "ocp-ocamlres.0.4"
  "ocplib-endian.1.1"
  "ocplib-json-typed.0.7.1"
  "ocplib-json-typed-browser.0.7.1"
  "odoc.1.5.3"
  "omd.1.3.1"
  "optint.0.1.0"
  "parsexp.v0.14.1"
  "pprint.20200410"
  "ppx_cstruct.5.2.0"
  "ppx_derivers.1.2.1"
  "ppx_fields_conv.v0.14.1"
  "ppx_sexp_conv.v0.14.1"
  "ppx_tools.6.4"
  "ppx_tools_versioned.5.4.0"
  "ppxlib.0.15.0"
  "re.1.9.0"
  "react.1.2.1"
  "reactiveData.0.2.2"
  "result.1.5"
  "seq.base"
  "sexplib.v0.14.0"
  "sexplib0.v0.14.0"
  "ssl.0.5.5"
  "stdlib-shims.0.3.0"
  "stringext.1.6.0"
  "topkg.1.0.3"
  "tyxml.4.5.0"
  "uchar.0.0.2"
  "uri.4.2.0"
  "uri-sexp.4.2.0"
  "uutf.1.0.2"
  "vg.0.9.4"
  "yojson.1.7.0"
]

Finally, note that after doing opam install js_of_ocaml.3.9.0 (instead of js_of_ocaml.3.10.0), the build/deploy/loading is OK.

Questions

@AltGr if you can reproduce the issue, do you believe it'd be easy to figure out how to maintain the compatibility with this most recent js_of_ocaml version (if the issue really comes from js_of_ocaml… or maybe from a transitive dependency)?

Anyway, no worries if we can't fix this before Friday! in this case for the time being, I guess I could just push an upward constraint in the *.opam file, to be able to release 0.13 before the end of the week 😌

[erikmd]

FTR @AltGr just told me he managed to isolate and fix this bug (cf. ocsigen/js_of_ocaml#1130), thanks a lot Louis!

So indeed blacklisting in our *.opam the latest release of jsoo.3.10.0 for now seems the way to go.

[erikmd]

• I guess one can close this one, given PR Blacklist jsoo version 3.10.0 #420 is merged.