opam VS dune

Regarding toolchain managers, those developing software with Rust would use rustup, OCaml developers would use opam, Haskell GHCup, and Python with pyenv. Likwise, Rust already uses cargo for package management, Python can use pip and venv, cabal for Haskell, and opam still for OCaml.

The project has a planning board for 2.2 on https://github.com/ocaml/opam/projects/2 and there are many active PRs on the repo. I wouldn’t hazard an accurate ETA but it is being actively worked on right now.

nodc. (not opam, don't care)

Maybe you'll find this issue helpful (though I didn't): https://github.com/ocaml/opam/issues/3773

That being said, the experience on Windows could definitely be better. The bright side is that the community is aware of this and is making progress on improving it. If you're curious, you can take a look at some of the Windows-related plans for opam 2.2 (pdf).

With Dune, given the executable main, you would write the following dune file to use library mylib if it was published on Opam.

This is caused by bubblewrap requiring specific permissions when running in Docker containers. Disabling sandbox does make you install OCaml, but there is a risk of installation scripts of packages wiping home directory https://github.com/ocaml/opam/issues/3231

If you are using the dune build system, add the tag(s) to your dune-project file's package stanza. E.g.:

One way to get around this is to modify the api/dune file with (include_subdirs qualified); this means that every subdirectory of api/ can be referenced by module namespacing and we don't have to write dune files for every route (or pages) folder. However, the OCaml LSP does not like it and red squiggles will show up in the editor (although the app with still compile without errors). Trying to develop the app knowing those red squiggles cannot be vanquished would drive me nuts, so instead of using (include_subdirs qualified) I just wrote dune files for every route (and page) which gets rid of the red squiggles.

2) Neither would having all source/targets specified, as that would entail listing them all in the dune file as wildcard rules is apparently still not a thing: https://github.com/ocaml/dune/issues/307

There is a small example on the dune home page: https://dune.build/

Dune (https://dune.build/) is the preeminent build tool for OCaml development. I don't love its input syntax (s-expressions), and I sometimes miss the ability to write high-level functions to reduce boilerplate (especially for unit tests), but it always gets the dependencies right, and it's fast. This is in stark contrast to some of my experiences with various other build systems, and I am super happy that the default option for OCaml build systems is so good.

It's still weird because dune's own site only makes Jane Street references: https://dune.build/.

ONE of the big benefits of OCaml is its powerful REPL (also called the toplevel), the interactive command-line utility where you can load modules, type in and execute code, and see its results. The modern REPL, utop, has powerful auto-completion and integration with the build system dune, which enables productive workflows like loading an entire project's libraries in the REPL and interactively exploring them.