Open edwintorok opened 1 month ago
Actually I'm not sure whether :dev depencies would be the right way to support utop
, they're probably more appropriate for optional dependencies (e.g. benchmarking tools) that you do want available in your build environment to activate various optional
build rules.
dune
already has a dune utop
subcommand, so it'd be good if that installed utop
as a dev tool automatically, just like how dune fmt
installs ocamlformat
.
I think the right way in OPAM parlance is to mark these dependencies is to use the :with-dev-setup
variable.
Expected Behavior
dune utop
worksActual Behavior
Reproduction
1.dune init project dune_utop_test 1.cd dune_utop_test 1.Change the depends line to
(depends ocaml dune (utop :dev))
1.dune pkg lock 1.dune build 1.dune utopSpecifications
Version of
dune
(output ofdune --version
):Version of
ocaml
(output ofocamlc --version
):Operating system (distribution and version): Fedora 40
Additional information
Would be good if
utop
and other "tools" could be added to the "dev dependencies" lock, without actually becoming visible/available for the project itself.opam
doesn't really have good support for this either (there is some limited support for installing e.g. theopam monorepo
plugin into a tools switch?), but the new dune preview seems to support separate developer tool lockfiles, where tools like the LSP server, and ocamlformat go.