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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Tying environments to filenames in this way makes sense when an
> environment corresponds to a project which exists in the filesystem.

That was my assumption: your "environments" correspond to
specific subdirectories in the file-system.

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

Hard to tell.  Even the question is unclear to me.  The approach
I suggest assumes you don't need/want to make changes to what I consider
"core" and instead use existing hooks (in this case
file-name-handler-alist).  So it could be distributed via GNU ELPA,
for example.

> Also, in the future, it would be nice to have the ability to just run
> (something like) "M-x environment-switch" to switch the current buffer
> to a new environment, and have an invocation of e.g. "M-x compile" just
> work.

That seems to assume that an environment could be bound to a buffer
rather than a subdirectory, IOW it wouldn't be chained to
a subdirectory.  Such environments seem to introduce further questions
about how to determine which env to use for which buffer (IOW what UI
to expose to the user).

> Does anyone have any thoughts about how to eventually support that?

You could set file-name-handler-alist buffer-locally, maybe?

Still, the main issue is what to do about things that happen in other
buffers but which the user would consider as related.

>> And of course, yet another is to advice-add on call-process and
>> start-process.
> Yeah, but I'd like to be able to get this into Emacs (hopefully by 26).

You mean you want it distributed with Emacs?  Most new packages nowadays
end up in GNU ELPA rather than in Emacs, unless they offer functionality
needed by other packages that are distributed with Emacs.


        Stefan