Re: Buffer-local process environments

[Michael Albinus]

Augusto Stoffel <arstoffel@gmail.com> writes:

> Hi Michael,

Hi Augusto,

> I can only think of two alternatives:
>
> 1. Introduce a whitelist of variables that can be exported to a remote.
>    Then drop entirely the current hack and just check whether
>    `process-environment' contains any exportable variables.  For
>    flexibility, you can allow whitelisting a variable name (any value),
>    or a specific VAR=VALUE pair.
>
>    The whitelist can be set globally or dynamically.  So, for instance,
>    the vc files could just append "BZR_LOG", "HGPLAIN" and whatnot
>    globally to this list and never worry again.
>
>    Obviously, this will break third-party code, but the fix is quite
>    easy.  Nobody could bash you for that.

We have already a white list, which is tramp-remote-process-environment.
I'm reluctant to add package specific entries there by default, it would
be an endless story. PAGER is included as being a general purpose
environment variable, BZR_LOG and HGPLAIN are not. If packages believe
they shall be added, this could be done in vc-bzr.el or vc-hg.el. Tramp
is a stupid library, it shouldn't try to be clever.

> 2. Introduce a blacklist of variables that are never exported to a
>    remote.  This can be done by extending
>    `tramp-remote-process-environment' to follow the same convention of
>    `process-environment' that an entry of the form VAR, without the
>    =VALUE, means removing the variable.

There are already such variables to be unset. These are the variables
without any value, like "HISTORY="

>    So, for instance, entries "PATH" and "TERM" should be added to the
>    default value of `tramp-remote-process-environment'.  This would
>    solve the unintuitive (if not buggy) behavior I pointed out a few
>    messages back in this thread.

TERM is handled special. All Tramp connections add "TERM=dumb",
hard-coded. Since this shall not be changed by a user, it isn't
configurable here.

PATH is handled by tramp-remote-path. This is a variable on its own,
because just setting a simple string "PATH=/abc:/def" isn't sufficient,
often.

>    As another example, python.el would append "PYTHONPATH" and
>    "PYTHONHOME" globally to `tramp-remote-process-environment', since
>    these variables hold directory names.

Yes, if python.el developers prefer that. However, I doubt, that this
value is always the same for all different remote hosts, the value might
differ depending on the OS the remote host is running.

>    This option is fully backwards compatible, but keeps the hack you
>    said you don't like anyway.

So in fact, this solution is almost the current implementation.

> It's also conceivable do to both things, but instead of enforcing 1.,
> just give a warning.  Then eventually you could get rid of the hack
> without breaking other packages.

As said, variant 1. isn't applicable in my eyes.

Best regards, Michael.