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

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/24/2016 05:24 PM, Eli Zaretskii wrote:

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

Couldn't that be fixed? Anyway, I think using file-name-handler-alist is 
not a good idea because it'll make for worse debugging experience.

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

Maybe project.el will end up a misnomer (but I don't have a better name 
that is not too long). Essentially, if we tie the new feature to 
projects, that will likely limit its usability. Or at least if we do 
that in the obvious way I can think of.

Consider: if we just add a new defgeneric (or two) to project.el, any 
specialized environment implementation would either have to provide its 
own full project implementation (i.e. it'll be unable to use 
vc-project), or it'll have to define specialized implementations of 
these methods just for certain types of projects it knows about.

That's not to say that we couldn't add new defdenerics to project.el for 
the purpose of overriding the current environment setup... but I'd like 
to see some real use case for that first.