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

[sbaugh@catern.com]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

>> Does this approach (putting project root directories into
>> file-name-handler-alist) sound like something that could be accepted
>> into core Emacs? If so I'll get started.

OK, I implemented a very rough prototype of this. It is
attached. environment.el is the API that would go into Emacs,
guix-environment.el provides a command to use an guix-provided
environment, and test-environment.el is just a sequence of expressions
to evaluate to demonstrate them. (Not tests)


[-- Attachment #2: environment.el --]
[-- Type: application/emacs-lisp, Size: 4302 bytes --]

[-- Attachment #3: guix-environment.el --]
[-- Type: application/emacs-lisp, Size: 2365 bytes --]

[-- Attachment #4: test-environment.el --]
[-- Type: application/emacs-lisp, Size: 720 bytes --]

[-- Attachment #5: Type: text/plain, Size: 3141 bytes --]


I have run into a problem though with the file-name-handler-alist
approach. I don't think it will work in the long run. To recap, I am
using file-name-handler-alist to make sure that all operations on files
that are descendants in the filesystem tree of some project directories,
are specially handled by my environment code.

The problem is that paths passed to find-file-name-handler, such as
default-directory, are not necessarily canonical paths. But
file-name-handler-alist is an list of (REGEX . HANDLER), so I am only
able to textually match against the input path. So if a path passed to
find-file-name-handler contains ~ or .. or ., it might be that it is in
fact a descendant of a project directory, but it won't be matched by the
regex, and so it won't get specially handled.

I don't think path resolution can be done with regular expressions,
so this approach will never really work.

>My impression is that this will have to be fixed case-by-case.  There is
>a precedent for that, which is the handling of buffer-local settings.
>E.g. vc-diff is expected to obey the vc-diff-switches settings of the
>"original buffer" rather than those of the buffer where the process
>runs.  So we sometimes go through the trouble to read some variables
>before switching to the destination buffer.  Environments would "simply"
>fall into this case.  But yes, those issues will have to fixed
>one-by-one.

That treatment of vc-diff-switches does look very similar to the correct
treatment of environments. Since there are other variables that need to
be treated in this way, beyond just environments, maybe a generic
solution is possible? Perhaps the "new kind of dynamic buffer-local
variable" I mentioned earlier:

>- Make exec-path and process-environment a different kind of
>  buffer-local dynamic variable
>
>  The behavior of this variable would be that when it is defined locally
>  in the current buffer, it behaves like a normal dynamic variable. And
>  when it is not defined locally in the current buffer, looking up the
>  variable will look up the variable dynamically instead of looking for
>  a global value set with setq-default.
>  This would mean that when M-x compile is invoked from some buffer, if
>  exec-path and process-environment are not buffer-local in the compile
>  buffer, those variables will be looked up dynamically, and found in
>  the buffer-locals of the buffer that was current at the time of the
>  M-x compile invocation.
>  I don't know if this is possible given the implementation of dynamic
>  variables in Emacs Lisp.

This could be used for vc-diff-switches too, and other variables like
it. Having now read more about how dynamic variables are implemented in
Emacs, I guess this would require a fair bit of work though.

If a generic solution like this isn't possible, I can start working on
fixing things case-by-case as soon as a good design is worked out.

>I'm not maintainer any more so I don't need to make those decisions.
>But if I were maintainer, I'd need to see the code before I could make
>a decision.

OK, I'll wait until John expresses his thoughts. (Possibly after the
release?)