I wonder how this would affect the solver performance. What's the rationale for that change?

This fails

  "dependencies": {
    "ocaml": ">= 4.12.0",
  },
  "devDependencies": {
    "@opam/ocamlformat": "0.26.1",
  },

But the following works

  "dependencies": {
    "ocaml": ">= 4.12.0 < 5.0.0",
  },
  "devDependencies": {
    "@opam/ocamlformat": "0.26.1",
  },

Working on a fast test to repro this.

Error message was,

error: No solution found:                                                                                                                                    
                                                                                                                                                             
Conflicting constraints:                                                                                                                                     
  @grain/libbinaryen -> @opam/ocamlformat -> ocaml@>=4.8.0 && ocaml@<5.2.0                                                                                   
  @grain/libbinaryen -> ocaml@=5.2.0  

I wonder if the proper fix is to ask user to specify a concrete OCaml version. Maybe not through the package.json but interactively on the first project install?

I wonder if the proper fix is to ask user to specify a concrete OCaml version. Maybe not through the package.json but interactively on the first project install?

I think this is possible. If they specify the exact OCaml, follow the ocaml-specific solver flow.. If a semver range is provided, let the solver solve ocaml as any other package.

Yeah, in general it's just there are two types of ocaml constraints right now:

1. the package constraint
2. the project (= root package) constraint

I believe having 2. as specific as possible is a good thing because:

1. users would want to work with a specific OCaml compiler version, not picked "arbitrary" based on other constraints
2. this speeds up solver performance as it's much less packages/versions to consider

users would want to work with a specific OCaml compiler version, not picked "arbitrary" based on other constraints

Informed users: yes. But there's always someone who forgets, didn't read the documentation or simply disagrees with with the idea of (or finds it inconvenient) having to specify the exact version of ocaml compiler.

I'll see if it's possible to accomodate them as well.

Informed users: yes. But there's always someone who forgets, didn't read the documentation or simply disagrees with with the idea of (or finds it inconvenient) having to specify the exact version of ocaml compiler.

I suppose it is still a very rare case, only for fresh projects, as ocaml version is locked in esy.lock. Maybe exactly for this case an interactive selector could be present.

Are you suggesting that this interactive selector is triggered when the user hasn't specified the exact compiler version instead of trying to club ocaml together with other packages and solve?

Yes, basically if the following criteria are met:

• no esy.lock found
• no concrete (or no concrete enough? maybe just proceed if a constraint like 4.12.x exists, which is specific enough) ocaml version specified in package.json

then user is asked to select an OCaml version from available.