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

[sbaugh@catern.com]

Eli Zaretskii <eliz@gnu.org> writes:
> And having read all that, I still don't see why we would like to use
> file-name handlers for supporting these features.  My suggestion to
> embed such support directly in the affected primitives, like
> process-file, call-process, etc., still stands.  Would you please
> consider this possibility, and if you think it's inappropriate,
> explain why you think so?

I think I missed the suggestion when you made it earlier (or don't
recognize it as the same suggestion now) and I'm not sure I understand
it in this condensed form. Could you elaborate?

In particular I'm missing how directly adding environment support in
process-file etc. will handle the issue of, e.g., a user invoking M-x
compile, where we need to communicate the environment to use between
buffers.

> If you want an environment to be able to change its locale, then we
> must also pay attention to the following subtlety: the value of
> process-environment is stored by Emacs in its original undecoded form,
> i.e. in the encoding used by the "pre-existing environment"s codeset.
> Thus, supporting locale changes seem to require a separate variable
> that is used in preference to process-environment, and whose value is
> encoded according to the customized locale.

Hmm, it's indeed tricky that as locale changes, the encoding of all
other environment variables also needs to change (if I understand you
correctly). It was probably a bad example though because I doubt that
any environment-creating tools will set a different locale. If there are
some that do, it might be useful to look at what they do to handle
this...

> Would having a single user variable for controlling the above be a
> sufficiently nice UI?  If not, why not?

A single user variable controlling what environment we are in? Meaning
that Emacs is only ever in exactly one environment? That is not
adequate, it makes it difficult to work on different projects in the
same Emacs. And anyway a single environment approach can already be done
easily enough by writing a command to just swap between different values
for process-environment, exec-path, and so on.

>> However, TRAMP also needs to be able to support running processes on
>> remote hosts. And there its mechanism is rather unnatural - why
>> should we use a filename to identify the remote host on which we want to
>> run a process?
>
> In the context of running processes on remote hosts, this is actually
> very natural.  It allows Lisp applications to be stateless in this
> regard.
>
> By contrast, environments support cannot be stateless, because by the
> very definition, when a command is executed in a certain environment,
> then _all_ of the files and environment variables should be as the
> environment defines.

In what way does this allow statelessness, that it doesn't also allow
for environments?

This mechanism allows a Lisp application to ignore whether there is
currently a connection to a remote host, when trying to run a process on
a remote host, since the connection will be created by TRAMP
automatically - is that what you mean by stateless?

Environment usage can be just as stateless. The custom environment
identifier embedded into the file name can and should be enough
information to locate the configuration for the environment, load it
into Emacs, and start using it. Thus a Lisp application trying to run a
process in an environment can ignore whether the environment is
currently in use by Emacs.