Re: Profiles/manifests-related command line interface enhancements

[Mark H Weaver <mhw@netris.org>]

Hi Pierre,

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> It wouldn't be sufficient to remove them.  You'd have to restore the
>> previous settings.  For example, if we remove the settings for PATH,
>> MANPATH, etc, without restoring the previous settings, I doubt that you
>> would be pleased with the results.
>
> I don't understand.
> Which previous settings?

I'm talking about the previous values of the environment variables, as
they existed before activating the new profile.

> As far as I understand, activating a profile never _removes_ any value
> from environment variables.

It doesn't remove them, but it overwrites them, thus losing the
information of what the previous environment was.  Now, it's true that
for *most* of those environment variables, the previous value is a
suffix of the new value, but that's not always the case.  One notable
counter-example is GUIX_PROFILE itself, which is simply overwritten.
Others include GIT_EXEC_PATH and ASPELL_DICT_DIR.

>> It seems to me that the most natural approach to allow restoring the
>> previous environment settings is to launch a subshell when you activate
>> a profile.  That subshell can then simply be exited to restore the
>> previous settings.
>
> I gave the example of EXWM, for which the user would like to change the
> profile but a subshell won't do since it won't reflect on the parent
> process, Emacs.

There's no way to change the environment variable in Emacs without
running Emacs lisp code, e.g. by running M-x setenv.

In general, every process has a complete copy of its own environment
variables, which live in its own address space.  When a process launches
a child process, it gets to decide what the child's initial environment
will be.  Usually, but not always, programs pass a copy of their own
environment to child processes, and there are convenience functions that
make this common case easier.  From the kernel's point of view,
environment variables are passed to child processes exactly the same way
that command-line arguments are, although by convention they are treated
differently by user interfaces.

There's no mechanism for child processes to ask their parent processes
to modify their environment.  Each program needs to provide its own
mechanism for modifying its internal environment, and most don't even
provide such a mechanism.  For example, Ratpoison provides a command to
modify its own environment (C-t setenv, iirc), but I have no idea how to
modify gnome-session's environment.

Note that I'm not passing judgement on the merits of your proposals, I'm
merely letting you know that they cannot be implemented as envisioned,
at least not if I understand correctly.

     Regards,
       Mark