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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 18 Nov 2022 15:38:34 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: emacs-devel@gnu.org
> 
> > 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?
> 
> It seems to me that while project.el could acquire the notion of
> sub-projects, the *meaning* of a sub-project would be entirely
> specific to the tool which needed it (eglot in this case).  And if you
> had multiple tools which each wanted some kind of sub-project, you
> might find that some of the sub-projects were overlapping others,
> depending on the needs of the tools which each one was related to.
> 
> Still, if eglot could ask project.el for "the nearest sub-project
> defined for 'eglot' usage, if any, and otherwise the main project" and
> project.el had been told that for the project at /path/to/proj there
> was an 'eglot' sub-project at /path/to/proj/subdir/foo, then that
> could be useful.
> 
> So project.el could provide an API for defining and returning
> sub-projects, but it would be up to eglot (or other tools) to cause
> such sub-projects to have any kind of effect, and it would be up to
> the end-user to define their 'eglot' sub-projects in the first place.

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 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.

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

I would also like to hear from Dmitry what are his thoughts on this.