Re: Managing environments (Python venv, guix environment, etc.)

[Eli Zaretskii <eliz@gnu.org>]

> From: sbaugh@catern.com
> Date: Mon, 25 Jul 2016 01:01:49 -0400
> 
> > One possible idea is to identify the programs that an environment
> > would like to depend on it (like the compiler), define a variable for
> > each one of them (compiler-program etc.), and then modify the
> > corresponding commands to use that variable, if bound to non-nil, in
> > preference to exec-path search.
> 
> The environment also matters, so you'd need to have a
> compiler-process-environment too.

Sometimes, yes.  But this is definitely for the project to set up.

> Note: The compile command already makes use of a compilation-environment
> variable.

Then we already do what you want, right?

> That would work, but again, it means updating the entire world to
> support this.

No, it means we need to make specific changes in specific primitives
and infrastructure functions.  Those which currently only look at
exec-path, and are involved in invoking development tools for which we
will want to provide this support.  E.g., "M-x compile" will be able
to invoke the compiler specified by the environment, "M-x gdb" will be
able to invoke the debugger specified by the environment, etc.

We could also have wrappers like call-compiler, call-debugger, etc.

> Also, if we're going to update the world: Perhaps just add
> buffer-local variables "local-exec-path" and
> "local-process-environment", and flags like
> "compile-use-local-environment" which if non-nil cause the relevant
> command, when invoked, to use the local-exec-path and
> local-process-environment variables from (current-buffer). That seems
> more natural to me.

But that's exactly the danger I think we should try to avoid: a Lisp
application doesn't have good control of when buffer-local bindings
will be in effect, because Emacs internals feel at liberty to
temporarily switch to any buffer when they feel like it.  These
buffer-local bindings will bite you when you don't expect.

That's why I think the environment should be only allowed to override
file names of a specific limited set of tools, not the entire
exec-path.