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

[Tim Cross]

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.

Just a thought, apologies if I've missed something as I'm coming to this
late....

I"m making the basic assumption that a project, from the eglot
perspective, is what project.el tells it is a project. 

Is this something which should be addressed at the eglot level or at the
project level? It seems to me that what you really have here is a main
project which consists of a number of sub-projects and that it could be
beneficial more generally if you could more easily isolate out the
sub-projects (not just for eglot, but possibly for other tools as well)
at the project.el layer rather than the eglot layer. This could mean the
user has to be more involved in defining the project and sub-project
structure/relationships, but that may be reasonable when you have more
complex project structure?

I guess my question here is whether the focus should be on enhancing
project.el rather than modifying/enhancing eglot.el to handle this use
case?