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

[sbaugh]

Eli Zaretskii <address@hidden> writes:
> 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.

I don't think that would be an issue. At the moment, the primary place
to use these kind of special environments is a Unix shell. If basic
tools like coreutils weren't in the environment, the environment would
already be useless for the user. And the only way to get some kind of
useless environment like that would be to explicitly configure it; I'm
inclined to call that user error. Also: These special environments
typically just prepend new directories to PATH and other vars,
"inheriting" the binaries that were in the user's pre-existing
environment, and just overriding some, so in the typical case things
will certainly work fine.

Also note: If a binary from outside some project-specific environment is
run within that environment, it might break. (Maybe you preload some
crazy library within the project-specific environment, and have a set of
project-specific binaries that know how to cope with that.)

So if we don't modify exec-path to be project-specific, then anything
that wants to run a process inside the project-specific environment
would need to be explicitly modified to search the project-specific
path, to avoid running outside binaries inside the special
environment.

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

Yes, a new program that wants to search per-environment search paths
could use locate-file. But I still hope for not needing to modify things
to be environment-aware.

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

Well, also the build system and the debugger. And maybe if you're
developing a browser, you'd want browse-url to pick up the version
compiled in the project-specific environment when you're working on it.

In general I think it's entirely reasonable to want to be able to run
project-specific version of developer tools. The compiler/interpreter is
the most obvious project-specific program, but there are benefits to
supporting running every developer tool inside the project-specific
environment.

Here are three benefits that I see for running everything within the
project-specific environment by default:
- This works identically (and therefore compatibly) to the Unix shell
inside a special environment.
- Any other project-specific developer tools that we don't know about or
don't yet exist, will be automatically supported.
- And most importantly: all the myriad programming modes for Emacs with
their many custom methods for running their compiler/interpreter, will
automatically support running their compilers/interpreters in an
environment-aware way.

However I admit that if the user wants to run a development program from
outside the project-specific environment (or even a development program
from another environment) it could become a little more tricky...

And the conceptually easiest way is still just updating Elisp commands
(such as compile or shell-command) one by one to be environment-aware.