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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Eli,

I was going to comment, but this thread has run away quicker than I 
managed to compose a reply.

On 07/23/2016 10:10 AM, Eli Zaretskii wrote:
> Actually, I don't like to see any feature, let alone a core one, use
> file-name-handler-alist for local files.  Lots of code in Emacs,
> including primitives, really handle such files as remote, so the
> results are likely to be incorrect and subtly broken.

We do have file-remote-p, don't we? Maybe the code in question should be 
fixed.

> I always thought that features like this one should use and extent
> the infrastructure in project.el.  And yet Dmitry is silent in this
> discussion.  What am I missing?

I don't know exactly if project.el is the best place for it. Maybe we 
should see how well environment.el works as a separate feature, and if 
that makes sense, incorporate it after.

My main concern with this proposal is avoiding to have to purposefully 
modify "every Elisp package that runs processes". If every process call 
will pass through the environment dispatcher, that's bound to add some 
overhead. How will that affect the code that makes multiple process 
calls at once, such as VC? I'd like to see some numbers.

And if we base this feature on project.el right away, it will add a 
stricter requirement on the performance of `project-current', which is 
currently called at most once per user command. We could add some cache 
there, of course.

Alternatively, we can keep environment.el separate, and any advanced 
minor mode, such as EDE, would both hook into project.el and set up any 
necessary environment.el variables.