[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Managing environments (Python venv, guix environment, etc.)
Date: Mon, 25 Jul 2016 03:05:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]