Emacs and the environment variables

Learning
1

I am a new user. I had 2 days of frustration because Emacs and REPL did not work as expected because of missing environment variable: CAML_LD_LIBRARY_PATH. Is this the last surprise? What else should I expect?

2

Hard to answer such an open-ended question :slight_smile:

As a general rule, Emacs is well supported by the OCaml tooling. If you are using OPAM it should be enough to execute Emacs under the OPAM environment (eg opam exec -- emacs or eval $(opam env)).

The Emacs-included LSP client eglot works out of the box with ocaml-lsp (assuming you use Dune to build your project).

Cheers,
Nicolas

3

At least on macos, how to get a proper environment in emacs’s gui remains an extremely convoluted problem. I revisit the problem from time to time. Last time it seems it was in 2022 that’s what I have in my init.el:

;; Load paths (needed to get correct env)
;; It's 2022 and still no good solution exists for that.
(require 'exec-path-from-shell)
(dolist (var '("PAGER" "PDFVIEWER" "BROWSER"
               "LIBRARY_PATH" "C_INCLUDE_PATH" "PKG_CONFIG_PATH"
               "OPAM_SWITCH_PREFIX" "CAML_LD_LIBRARY_PATH" "OCAMLTOP_INCLUDE_PATH"
               "OCAMLRUNPARAM"))
  (add-to-list 'exec-path-from-shell-variables var))
(exec-path-from-shell-initialize)
4

Just to confirm, this refers to the situation when you double-click on the app, as opposed as launching it from a terminal, is that right?

Cheers,
Nicolas

5

Absolutely. The package I’m using here to solve the problems has more details.

6

good answers to open-ended questions can save someone lot of frustration

your suggestion about opam exec – emacs may pay off in the future, thank you very much

7

I’m using envrc along with direnv to maintain environment variables.

https://lambdafoo.com/posts/2022-09-07-ocaml-with-emacs-2022.html

2 Likes
8

Ah yes I always remember you once wrote that and that I should maybe switch to it.

But I’m not to keen to add an .envrc to 100+ repos and my problem is that I rarely use local opam switches. Rather I have two of them, global. One for the latest OCaml version I mostly support (4.14 nowadays) and one for the latest OCaml version.

When you publish a lot of packages, “per project” switch management is rather inconvenient and brings less hands-on testing when you pin and try to live for a while on what is going to be the next version of a package.

I’m still wondering whether maybe that could work at the ~/.envrc level and take care of my global opam switches (which after trying a few more sophisticated things in the past I handle for now by simplying restarting emacs :–)

9

I have this at the top of my tuareg-mode hooks:

  (opam-update-env (projectile-project-root))

I work with dev switches for everything (eased a bit by nomad), but I think this would do the trick even if you just use a few switches globally, since opam-update-env asks for the env from whatever switch is activated.

Sometimes I will notice the env gets a bit out of sync for some reason, and then I’ll execute opam-update-env directly.

(Caveat that I use doom, so that may do something more magical that I am accounting for here.)

1 Like
10

Yep, this should work. I use a similar setup for python projects, where I have a workspace with multiple project directories and a shared virtualenv. The .envrc goes in the workspace directory.

1 Like
11

I tend to have one default global opam switch for everything I don’t mind mixing opam dependencies (currently 5.2), a switch for the oldest OCaml I care about (4.08), and then setup specific local switches for projects I want to isolate. Currently at 34 switches.

Moving between projects using envrc works reasonably well, a few Emacs modes have bugs when changing environments which can usually be fixed with envrc reload all command. No need for restarting emacs.