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

[Eric Abrahamsen]

Danny Freeman <danny@dfreeman.email> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I think this turns the table for no good reason.  I see no reason to
>> add complex new abstractions to project.el just because we have an
>> issue with configuring Eglot in the use case presented in this thread.
>>
>> Let me remind you that Eglot already supports a kind of "sub-project":
>> it uses the same LSP server only for those source files in a project
>> that share the same major mode.  So parts of a project that use a
>> different PL are already considered to be a "sub-project", and Eglot
>> does that without any help from project.el.
>>
>> Given that this feature already exists, a proposal to add a
>> "sub-project" notion to project.el should describe at least several
>> use cases of such "sub-projects" where the separate "sub-projects"
>> share the same programming language.  If the situation with python-env
>> is the only one we find reasonable, IMO adding "sub-projects" to
>> project.el is an unjustified complication.
>
> I think that most monorepo projects fall into this category. That is a
> large version controlled repository with multiple sub projects in it.
> Sometimes the subprojects are written in different languages. Usually
> there are sub folders of the monorepo project that act as sub projects.
> I ran into one at work yesterday, but I'm not sure what I would have
> project.el do differently there. I preferred it's behavior actually. 
>
>> I suggest to look at this as an Eglot issue, not a project.el issue.
>> What is requested here is an ability to tell Eglot which directories
>> should share the same LSP server and which ones should have separate
>> servers.  It shouldn't be hard to have a buffer-local variable to tell
>> Eglot that, or a function that accepts a buffer and returns a value
>> that Eglot can use for this decision.  All we need is a way to tell
>> Eglot which directories to communicate to the LSP server as those
>> which it should watch, and when to start another instance of the LSP
>> server even though one is already up and running for this project and
>> major mode.  Let's not complicate project.el for a problem that
>> doesn't belong to it.
>
> Is this not exactly what `eglot-lsp-context` is for? Using my example
> from earlier in the thread is what I suspect is the "right way" to solve
> this:
>
> ```
> (defun project-find-virtualenv-for-eglot (dir)
>   (when eglot-lsp-context
>     (let ((root (locate-dominating-file dir ".virtualenv")))
>       (when root
>         (cons 'transient root)))))
>
> (add-hook 'project-find-functions #'project-find-virtualenv-for-eglot)
> ```
>
> It can be made more targeted by checking the value of directory if
> necessary. (I could also a use when-let)
>
> It is an obscure way to solve this problem. I only know about it from my
> time spent with eglot's source. Not every user will have that
> experience. How could we make that better?

I agree that this seems like the most likely point of customization --
and also agree that if this approach gets "blessed" somehow it could
probably be made more obvious, if only through documentation.

I wonder if the same entry point could be used for language server
short-circuiting: for instance, the transient project structure could
contain a sexp that's used to mask the value of `eglot-server-programs',
to point Eglot at different programs. It looks like that value would get
cached for later use.

Anyway, I haven't looked at Eglot closely enough to suggest anything
more than that. I'll try to read through the library this weekend.

Eric