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

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22/11/22 23:40, João Távora wrote:
>> Rather it's the fact that the monorepo is clearly organized into
>> loosely coupled
>> sub-projects and very often (but not always) it makes sense to do
>> sub-project
>> wide file-finding and reference-finding.  No LSP/Eglotness involved at all.
>
> Speaking of monorepos, it seems to me that the boundaries between
> subprojects (or just nested projects) might not be defined by
> language-based separation of app directories, but rather by
> organizational needs (e.g. how teams are split). Teams could be
> backend-frontend-some-other-end, or they could be full-stack too.

That's right.  Indeed that's a very common case and makes a perfect case
for sub-projects: multiple loosely interrelated hierarchies of code
living inside a monorepo.

> IOW, the "subproject" structure needed by Eglot and one that looks
> natural to developers might quite well be different.

Eglot doesn't need any structure: it's some LSP servers who want to be
launched in a specific LSP workspace, which Eglot equates to a Emacs
project -- and that could be well sub-project.  I'd say very often the
LSP concept of "workspace" would match one of the logical team
sub-projects, but if they don't, there's a perfectly workable current
eglot-lsp-context solution.

>> As I explained earlier, it would also help if project-files weren't
>> so "flat list"
>> oriented and allowed generalized collections, such as my completion table
>> based on a very fast external indexer.
>
> That's a separate feature request.

Yes, it is.

João