Redundant dune version constraint

[reynir]

Expected Behavior

In dune-project I have a

(package ...
  (depends
    (dune (>= 3.16.0))
    ...)
  ...)

This generates an opam file with

depends: [
  "dune" {>= "3.16.0"}
  ...
]

Actual Behavior

The generated opam file contains duplicate version constraints:

depends: [
  "dune" {>= "3.16" & >= "3.16.0"}
  ...
]

Reproduction

robur-coop/mirage-swapfs@f9e946b

Specifications

• Version of dune (output of dune --version): 3.16.0
• Version of ocaml (output of ocamlc --version): 4.14.2
• Operating system (distribution and version): debian 12

[reynir]

Alternatively, I would expect a warning about the redundant version constraint.

[reynir]

Yet another alternative could be to make dune init emit a dune-project where package (depends ...) does not contain dune as it seems to get automagically emitted anyway in the resulting opam file!

[Leonidas-from-XIV]

Personally I agree that dune init should not emit a dune-project which contains dune; this has caused some issues already, so maybe that's the "simple" way out.

The reason why the constraint is duplicated is that if there is some constraint then dune will merge this constraint and also add the (>= dune-lang-version) constraint instead of throwing out the users constraint or throwing out dune's automatically added constraint.

The issue you run into is that your constraint is asking for 3.16.0, while the constraint that is added is 3.16 thus they are technically not equal (I think 3.16.0~alpha0 would satisfy one but not the other). There might be a valid case for requiring dune >= N+1 despite dune-lang N which will generate { dune >= N & dune >= N+1 }. We could attempt to merge them into the highest version but I worry that this might become quite tricky and unintuitive as the user-supplied constraints can potentially be complex.