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

[Phil Sainty]

On 2022-11-18 11:21, Tim Cross wrote:
> 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?

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.