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

[Eli Zaretskii <eliz@gnu.org>]

> From: sbaugh@catern.com
> Date: Sat, 30 Jul 2016 09:30:59 -0400
> 
> 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.

The communication will be through variables that process-file and
suchlikes will use in preference to exec-path.

If that's still not detailed enough, please ask specific questions,
because I don't understand what could be unclear about that.

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

So can we agree that customizing LANG b y an environment is currently
out of scope?

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

A variable can be buffer specific.  When I said "single", I meant a
single symbol, not a single instance (a.k.a. "global variable").

So the question still stands.

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

I thought I just explained that (above).  I'm not sure what to say
more.  Lisp applications don't need to know whether the process will
run on the local or remote host.  Perhaps you should look at the
internals of process-file.

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

Yes, and more: the application simply doesn't know where the process
will run.

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

I don't think we want the environment embedded in file names.

> Thus a Lisp application trying to run a process in an environment
> can ignore whether the environment is currently in use by Emacs.

I don't see how the application could ignore that, since it must
create those special file names to begin with, right?