Dune-project developer workflow confusion

When we set up a new dune project with its own local opam switch for sandboxed development, the workflow doesn’t seem right. Unless they know exactly what to do here, I feel like the developer would get stuck. Here’s an example:

$ dune init project my_proj
$ cd my_proj
$ opam switch create .
$ eval $(opam env)
$ dune build
command not found: dune

It’s a chicken-and-egg problem.

I’ve heard rumblings of tooling to solve this problem, and wanted to check in–is there any movement on this? Or at the very least, shouldn’t a new switch install dune by default so that we can kick off an initial build, add new dependencies to the dune-project file, and update the my_proj.opam file?

If you are thinking, well why not run a dune build before creating and activating the new switch? Obvious problem–the compiled artifacts could end up being for a different version of OCaml.

Sounds like what drom was created for! (I never used it though.)
Would the correct first command here be opam install . --deps-only?

$ opam install . --deps-only
[WARNING] No package definitions found at /Users/yawarquadiramin/src/my_proj
Nothing to do
$ cat my_proj.opam

Got into a similar issue after an 5.0.0 → 5.0.1+trunk OCaml upgrade. It seems while opam find robust and complete, dune feels still quite fragile and immature, at least in comparison, esp. when you come from Rust, Go, Ruby or JS/Node.

I believe these problems would be solved in a build-system agnostic way if this old proposal was implemented in opam.

We could then even streamline the opam switch create . workflow by letting it read ./opam and do an equivalent of install . --deps-only after the switch is created.


This is my usual setup for a new project @yawaramin

$ dune init project my_proj
$ cd my_proj
$ opam switch create . 4.14.1 --deps-only --with-test -y
$ eval $(opam env)
$ dune build

When you add a new dependency to an opam file re-run:

$ opam install . --deps-only --with-test -y

The workflow is not ideal and the tooling should handle adding new dependencies and new version constraints in a less manual way IMHO.