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

[Eli Zaretskii <eliz@gnu.org>]

> From: sbaugh@catern.com
> Date: Fri, 29 Jul 2016 16:57:46 -0400
> 
> An environment is a collection of environment variables paired with
> values for those variables. A program is said to run in the environment
> when it runs with those environment variables set to those values. Other
> environment variables might be set to arbitrary values.

Thanks.  This needs to be augmented by a list of the environment
variables that are handled specially in Emacs and therefore needs more
than just asking the "environment" in its Emacs incarnation to modify
process-environment as it sees fit.

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?

> LANG is a configuration variable containing the name of the current
> locale.

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.

> environment.el would allow using a given "custom environment" to run a
> program in Emacs in either a "pure environment", or a "combined
> environment" created from the custom environment and the "pre-existing
> environment" of Emacs. Ideally, environment.el would provide a nice user
> interface for doing that.

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

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

> By the way: In future work I would like to support editing files located
> inside chroots, containers, different mount namespaces, and so on.  In
> all those cases it makes sense to have a magic prefix to identify where
> to look, and then the file name; and in all those cases the files could
> (eventually, with work in C) be directly visited on the local machine
> rather than transferred over the network. So in those cases it's very
> clear to me that file-name-handler-alist should be used, and since TRAMP
> basically assumes transferring files over the network/through a
> subprocess, a new file-name handler should be made.

We will have to discuss those separately.  In any case, these features
are much more about files and filesystems than environments, as you
have described them.