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

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@catern.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 24 Jul 2016 15:05:52 -0400
> 
> Why would the effect be so significant?

For the same reason as load-path.

> Is exec-path used internally somehow in some confusing and tricky
> way?

It's used in the same messy way as load-path, just for looking for
different kind of files.  And it is as pervasive as load-path.

> If it's just Elisp using exec-path, it doesn't seem like messing
> with exec-path would be that subtle or difficult.

Not just Elisp, C primitives as well.  And even Elisp can be messy if
it's in preloaded packages like files.el, subr.el and simple.el.

IOW, I simply fail to see how we will be able to avoid disrupting the
most basic features if we modify exec-path.  Even visiting a file can
fire up a subprocess -- how do we make sure the right program for that
will still be found, if we let some project's environment mess with
exec-path behind the user's back?  And what about spellers (e.g., for
ispell-check-comments-and-strings)?  Etc. etc.

Once again, why not use locate-file?  CEDET and EDE already do, and I
assume for good reasons.

More generally, why would a project want to modify exec-path? to find
which programs?  Is it only the compiler/interpreter of the
programming language used by the project, or something else as well,
and why?  E.g., I don't really understand your example with browse-url
-- why would I want to change a browser as function of the project I'm
working on?