emacs-devel
[Top][All Lists]
Advanced

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

Re: Eglot, project.el, and python virtual environments


From: Yuan Fu
Subject: Re: Eglot, project.el, and python virtual environments
Date: Thu, 17 Nov 2022 10:48:20 -0800


> On Nov 17, 2022, at 10:06 AM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> 
> Danny Freeman <danny@dfreeman.email> writes:
> 
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> 
>>>>> project_root
>>>>> ├── .git
>>>>> ├── src
>>>>> │   └── python
>>>>> │       ├── VeryImportantLambda
>>>>> │       │   └── .venv
>>>>> │       ├── MoreImportance
>>>>> │       │   └── .venv
>>>>> │       ├── RunInCaseOfEmergency
>>>>> │       │   └── .venv
>> 
>> I just realized you posted information about the .venv files in your
>> original post and I completely overlooked that lol. 
>> 
>>> Thank you very much, that does help indeed! I started off down this path
>>> and had gotten as far as eglot-lsp-context. Then I realized I couldn't
>>> just return a directory, it had to be a project object, and that's when
>>> I decided someone else must have a better approach. But it's great to
>>> see all this laid out, and knowing about `(cons 'transient root)' is
>>> very helpful, as well.
>>> 
>>> I'll play around with this a bit. It seems like a not-outlandish
>>> situation, and I wonder if it might not be useful to provide some
>>> standardized method of helping Eglot find an alternate project.
>>> 
>>> Thanks again,
>>> Eric
>> 
>> Anyways yeah, I think I've heard about someone else running into this as
>> well. Maybe it was on the reddit emacs forum. Either way, I do not think
>> you are the first.
>> 
>> What might an extension for Eglot look like? Maybe a built in
>> `project-find-functions' implementation that does something similar
>> looking for a `.eglot-lsp-root` (or probably something configurable) as
>> a transient project root? I don't know if that would cause problems out
>> of the box for some people, but it seems safe.
> 
> That was my first thought: a file cookie that told Eglot to consider
> this directory a project root.
> 
> But I don't know enough about Eglot and its internals to be sure. I'm
> not even really sure what Eglot uses a project definition for: I guess
> to decide which buffers in a given major-mode should use the same
> invocation of a language server protocol? One process used in all those
> project buffers? Is that even how it groups things? I don't know.

AFAIK eglot uses project.el for finding projects.

> 
> The core issue in my case is that I need to be able to tell Eglot to use
> a separate language server executable for all python-mode buffers within
> a certain directory tree. Maybe there is a simpler way of doing that
> that doesn't require me to trick Eglot into thinking the project is
> smaller than it is. All a virtual environment does, fundamentally, is
> munge PATH so that Python-related executables are found locally, rather
> than system-wide. Maybe there's a relatively simple way to explicitly
> tell Eglot to do that.

You can add dir-local variables and set eglot-server-programs for each 
directory differently, each mapping python-mode to different server 
executables. (And also use .project.el cookies to limit the scope of the 
project.)

> 
> I think the approach I'm on now can probably be made to work, but it
> would be nice to know if there's a simpler way. I might spend a bit of
> time looking at Eglot's source, and open a bug report.
> 
> Thanks!
> Eric

Yuan


reply via email to

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