You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a package depends on a non-dune package and a specific version of the compiler the error message displayed when running opam monorepo lock does not mention the fact that the failure was due to a dependency on a non-dune package. For example, locking the following package:
opam-version: "2.0"
depends: [
"ansicolor" # ansicolor does not depend on dune
"ocaml" {= "4.14.1"}
]
The error message will be (the package name was "qux"):
The only problem with this package is that the dependency ansicolor does not build with dune, but the error message could lead users in the wrong direction when debugging this issue.
Note the ansicolor.0.5: Doesn't build with dune, which is omitted in the original error message.
After commit 46b287f the error message is expected to be:
opam_monorepo.exe: [ERROR] Some dependencies cannot be built with dune!
opam-monorepo requires that all dependencies use dune as their build system.
These dependencies (possibly transitive) don't use dune as their build system:
- ansicolor
The dune-universe opam repository (git+https://github.com/dune-universe/opam-overlays.git) contains dune ports of some popular packages to help build more packages with dune however it appears to already be set up on this switch. Thus it is possible that no dune port exists for any of these packages.
For information on how to contribute a new dune port, see: https://github.com/dune-universe/opam-overlays
Removing the version constraint on the "ocaml" package causes the problem to go away.
Note that on the latest release of opam-monorepo (0.3.5) this error doesn't seem to happen, though opam monorepo lock succeeds with no error message and proceeds to generate a lockfile which doesn't download ansicolor at all, which I assume was a bug that has since been fixed.
The text was updated successfully, but these errors were encountered:
gridbugs
changed the title
The <package> Doesn't build with dune error is omitted from opam monorepo lock in some cases
The <package> Doesn't build with dune error is omitted from the output of opam monorepo lock in some cases
Apr 28, 2023
gridbugs
added a commit
to gridbugs/opam-monorepo
that referenced
this issue
Apr 28, 2023
This is a workaround for
tarides#385. The error message
displayed when a dependency doesn't build with dune is misleading in
some cases. This adds a check that direct dependencies all have
available versions which build with dune before running the solver.
When a package depends on a non-dune package and a specific version of the compiler the error message displayed when running
opam monorepo lock
does not mention the fact that the failure was due to a dependency on a non-dune package. For example, locking the following package:The error message will be (the package name was "qux"):
The only problem with this package is that the dependency
ansicolor
does not build with dune, but the error message could lead users in the wrong direction when debugging this issue.The expected error message is (prior to 46b287f):
Note the
ansicolor.0.5: Doesn't build with dune
, which is omitted in the original error message.After commit 46b287f the error message is expected to be:
Removing the version constraint on the "ocaml" package causes the problem to go away.
Note that on the latest release of opam-monorepo (0.3.5) this error doesn't seem to happen, though
opam monorepo lock
succeeds with no error message and proceeds to generate a lockfile which doesn't downloadansicolor
at all, which I assume was a bug that has since been fixed.My hypothesis for why this is happening is after the solver concludes that no solution is possible, it gets run again, passing
~closest_match:true
(https://github.com/ocaml-opam/opam-0install-solver/blob/a17703ba83374975633d66bea2d40da51beabee5/lib/solver.ml#L57). The solver doesn't know that it's more useful to pick a partial solution whose diagnostics will include the fact that it failed due to a package having no versions that build with dune.The text was updated successfully, but these errors were encountered: