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

[Stefan Monnier]

> I do think it's best to use the same mechanism (process-file) that is
> used to support remote access.

Fully agreed.  Which is why I thought the file-name-handler-alist was
probably a good way to do it.  It's true that there are places where
file-name-handlers are misused, so I understand Eli's concerns, but I'm
not as worried about it as he is:
- as long as you don't use "environments" nothing should be affected, so
  if there are bad interactions, they will only show up when you use the
  new feature.
- we already have the tools to fix those interactions (such as
  `file-remote-p').
- we already have other non-remote file-name-handlers (jka-compr, and
  /: come to mind, and you could argue that some uses of /su: and /sudo:
  fall in the same category), so it's not a new problem.
- if we bump into problems, these are probably problems that also
  affect other uses, so we should fix them anyway.

This said, maybe it would work better to add environment support
directly to process-file and start-file-process (and anywhere else that
needs it) rather than use file-name-handler-alist.

I'm not worried about the performance impact on process-file and
friends, since it shouldn't affect that performance any more than
file-name-handler-alist already affects it and it should only affect it
when environments are actually used (and even in that case, the impact
should be dwarfed by the time it takes to fork, set things up, exec,
...).

> Perhaps instead of inserting regular filenames into
> file-name-handler-alist, environment.el should use filenames with a
> custom prefix (like "/?" or something) and add a new handler for
> filenames with that prefix.

That would solve the problem of failing to catch the environment name
because an alias was used, indeed.  OTOH if those environments already
exist outside Emacs and are already associated with existing directories
outside Emacs, it would be a lot more convenient for the user to be able
to use those directories directly instead of having to use a special
/?... syntax (with the added burden of having to tell Emacs which env
corresponds to which dir, ...).


        Stefan