A few questions from a new OCaml-er, old FP-er

Hi folks -

Haskell is my primary functional language these days, but I recently started looking at OCaml ahead of this year’s Advent of Code. After struggling with the standard library situation a bit, I’ve settled on Jane Street’s Core and things are moving along relatively smoothly. I have a few (somewhat unrelated) questions for the more experienced people in this ecosystem.

  1. Is there any way to run a single test via dune test? I’m using ppx_expect and there seems to be no granularity finer than a dune library.

  2. For folks using Core, do you manually open Core at the top of every module or do you add a compiler flag to your dune configuration to implicitly open Core?

  3. Is there a simple way to auto-activate local opam switches? Having to manually execute a command in the shell is a pain, especially considering I’ve already updated my shell configuration as suggested during installation to work with non-local switches. This is exacerbated by using a terminal multiplexer (tmux).

All in all, though, it’s been a surprisingly delightful experience thus far. The tooling is solid, the compiler is super fast, and the LSP library just works (this is a vastly underrated advantage in language ecosystems). If you’re curious, here is me stumbling through getting a reasonable repo together for this year’s contest.



I think it is better to add the flag. It is a bit more implicit, but if you do not you will get warnings in the rare cases where you use nothing from core.

For activating switches, I use direnv.

1 Like

opam itself will work, so the activation (that is, running eval $(opam env)) is for other programs. In my usage, only dune really matters, so it can be solved with a simple alias:

alias dune="opam exec -- dune"

Thanks, this is very helpful! Do you have similar aliases or use similar workarounds for running programs like ocamllsp and ocamlformat?

They should be present in PATH in the same shell the opam hook ran on. direnv would essentially require the same circumstances (both install shell hooks and run them on cd).
That means, if you rely on a shell-hook solution (opam’s builtin hooks, direnv, etc…), you have to start your graphic environment from the shell that got properly set-up with the hook. Recently I moved to ocaml-platform on vscode, and it handles the env for me, for every project I open.

For the unanswered point, I think running granular tests through dune is still WIP.

You can run individual folders of tests giving the path to that folder with dune test. You may need to add a dune file to that folder to make that work.

If I understand this correctly, you’re effectively saying what I said above – that the finest level of granularity for running tests is at the library level. Right?

I believe so, it’s a bit annoying but I think they are working on adding file and individual test granularity. But I’m not an expert dune hacker, mostly have just used it on large projects so someone else may be able to give a better answer.

1 Like

To get more granularity you could try another plugin for VsCode.

Thanks for this, but I’m using neovim today – which works great with ocaml-lsp-server for what it’s worth! I’d love to be able to use vim-test to run individual tests, as I do in Haskell, Elixir, Python, etc.

You can run individual tests by calling the actual test runner executable (not dune test) and adding -only-test.

The whole command looks something like this for the inline test runners that aren’t inline Alcotest tests

_build/default/test/foo/.LIBRARY.inline-tests/inline_test_runner_LIBRARY.exe inline-test-runner LIBRARY -only-test TEST_NAME

You get a list of tests by passing -list-test-names instead of -only-test. You want to add -verbose too. And you can pass -help.

Official documentation is GitHub - janestreet/ppx_inline_test: Syntax extension for writing in-line tests in ocaml code, but there are more than documented.
See Add documentation of command line arguments by Release-Candidate · Pull Request #45 · janestreet/ppx_inline_test · GitHub

There is also the option -matching substring.

Btw. these test runner executables get build by Dune only when running dune test (or dune exec with the test runner’s executable).

Feel free to ask me when you have any questions implementing the vim test runner. I do run a “list tests” first to get the ID of each available test to call them with “run test ID” if the user want’s to run the test ID.

Btw. there is one for PPX expect and inline tests as well. GitHub - Release-Candidate/vscode-ocaml-expect-inline: This extension lets you run OCaml Expect-tests and inline tests using the native Test Explorer

1 Like