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.
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.
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?
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.
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:
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.
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.
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.