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

[Danny Freeman <danny@dfreeman.email>]

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?

> Another evidence that this should be solved in Eglot is that "the
> other LSP mode" doesn't depend on project for this.

The other lsp mode solves this by prompting the user for the root
directory where the lsp server should start and remembers the user's 
choice. I'm starting to understand why they did that: it handles a lot
of the cases like this where LSP root != project root, but I think we
can do better than a prompt. The majority of the projects I work on lsp
root is the same as the project root and I like not being bothered by a
prompt.

I would also be interested in João's thoughts on how this could be
handled. Copying him.

-- 
Danny Freeman