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

[Eli Zaretskii]

> From: Danny Freeman <danny@dfreeman.email>
> Cc: Phil Sainty <psainty@orcon.net.nz>, Dmitry Gutov <dgutov@yandex.ru>,
>  theophilusx@gmail.com, emacs-devel@gnu.org, João Távora 
> <joaotavora@gmail.com>
> Date: Fri, 18 Nov 2022 08:55:35 -0500
> 
> 
> 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.

"Most"?  Maybe with Python projects (where I still doubt this
assertion, but have no experience to know for sure).  But otherwise
that is definitely not true.  Or else why would project.el decide to
consider a repository a single project?

IME, this kind of projects is a minority.