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

[sbaugh@catern.com]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> That was my assumption: your "environments" correspond to
> specific subdirectories in the file-system.

Nope, not necessarily. Python virtualenvs do have an associated
directory that contains the installed libraries for that
environment. But guix environment only updates environment variables to
point to the locations of already existing libraries, and so guix
environments don't exist in the filesystem at all. They're only a
runtime thing. (Libraries are installed on demand at fixed paths when
constructing an environment, and garbage-collected later)

However, people do mostly use environments only when working on a
specific project which exists in the filesystem, so I don't think it's
too big of a compromise to start with.

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

Oh, no, I do want to get this into Emacs. Because the use of these kind
of environments is pretty common at this point, and it would be nice if
Emacs natively understood them in a generic way. Then, yes, ELPA
packages could build on that functionality to support specific
kinds of environments. Same with the new project and xref functionality.

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

If an environment is manually set for the current buffer, then use that
one for all commands run.
Otherwise, if a buffer is visiting a file in a project, check for a
manually set or automatically detected environment for that project,
then use that environment for all commands run.
Otherwise, use the global environment for all commands run.

That seems like a decent UI. But in the manually set case, it is tricky
to implement, because of the related buffers problem...

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

Yes, otherwise just buffer-local exec-path and process-environment would
work okay.

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

Yes, I think this is important functionality that other packages
distributed with Emacs should be able to build on. Using virtualenvs is
very common for Python, for example, and Emacs should support that.

Also, since this is a headline feature of GNU Guix, it would be nice to
support it in GNU Emacs.