When developing software, it's often not possible or desirable to install compilers and related tools globally, so (barring the availability of fancy build tools) one has to fiddle with environment variables. Currently it's quite hard to set up Emacs to interact correctly with external tools on a per-project basis, because there is no unified way adjust the environment. For instance: - `M-x compile' has the `compilation-environment' variable. - python-mode uses `python-shell-virtualenv-root' when launching a REPL. - Eglot provides no other mechanism than setting `exec-path' and `process-environment' buffer-locally. - etc. Of course, the buffer-local variable approach will work with any command that doesn't switch buffers, even if that command invents its own method to adjust the environment. So why not make buffer-local process environments an official thing? By this I mean: 1. Fix commands that start external processes after switching buffers to do what the user means. 2. Provide a convenient way to set the process environment buffer locally. Point 1 is simple. I've attached a patch for `compile' as an example. In the Python REPL case, I'm not sure whether it would be better to just adapt `run-python' or make a change in comint itself. Proposal for point 2 -------------------- Add two more special keywords to the file local variable mechanism (besides `mode', `eval', etc): - `env' to add an entry to `process-environment'. - `path' to add an entry to `exec-path' and modify the PATH variable at the same time. Hence, the local variables section of a Python file might look like this: # Local Variables: # path: "~/path/to/some/virtualenv/bin" # env: "VIRTUAL_ENV=$HOME/path/to/some/virtualenv" # env: "LANG=C" # End: Of course, in practice it's more useful to include this in .dir-locals.el, but the mechanism is the same. Closing remarks --------------- As an indication that this is a real problem, let me point out a list of MELPA packages just to deal with Python virtualenvs: - auto-virtualenv - auto-virtualenvwrapper - conda - pungi - python-environment - pyvenv - virtualenv - virtualenvwrapper I've tried a couple of those and was never satisfied. My proposal here is inspired by the `inherienv' [1] and `envrc' [2] MELPA packages. The former provides an advice to solve point 1, the latter solves point 2 by means of an external program called direnv. [1]: https://github.com/purcell/inheritenv/ [2]: https://github.com/purcell/envrc