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

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 24 Jul 2016 06:26:41 +0300
> 
> 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.

No, I meant that we assume these are remote files without testing,
e.g. that primitives which support local files, like expand-file-name,
don't DTRT for them.  The code is written with that assumption in
mind.

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

It would sound strange to me that project.el fails to support
essentially the first serious client of its intended audience.

> My main concern with this proposal is avoiding to have to purposefully 
> modify "every Elisp package that runs processes".

Right.  Which is why I thought we should come up with some reasonable
way of supporting that without infecting "every package".

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

I actually am not sure what exactly is required by environment.el.
This discussion started by talking about environment variables, but
somehow we are now talking about such core functionality as load-path
and exec-path.  The latter is a far cry from the former, IMO.  I'm not
sure how we made that leap in the discussion.