Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)

[Eli Zaretskii]

> Date: Fri, 25 Nov 2022 23:57:51 +0200
> Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, danny@dfreeman.email,
>  eric@ericabrahamsen.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> The Lisp program that constructs instances of 'transient' is
> >> 'project-current'.
> > 
> > I meant to ask about building customized project objects, not the standard
> > ones that are already created by project-current.  This started with a
> > function João wrote to that effect, and he wrote it, AFAIU, because the
> > standard kinds of project objects didn't satisfy his needs.
> [...]
> > Again, you are talking about project kinds already supported by project.el
> > as its built-ins.  I'm asking how to produce a project of a custom type.
> 
> To produce a project of custom type, you decide the data structure for 
> that type, write implementations for all the required (and perhaps some 
> optional) generic methods, then create that structure.

It seems I need to spell out everything every time I'm writing something
because otherwise you interpret it out of context.  So here: I'm asking how
to produce a customized project whose type is 'transient', but which doesn't
go by the rules of the built-in 'transient' project.

As for "project of custom type", where "custom" means "not one of the known
types", there's still a situation where my project is similar enough to one
of the built-in types to make reimplementation of all the APIs overkill.
One could want to use some of the APIs without change and customize others.
So this, too, is something that project.el should IMO allow without too much
fuss.

> You asked, however, how to instantiate a project of a type belonging to 
> "someone else". But didn't explain why.

The "why" is "because one needs to".

> The reasons not to rely on internal structure, as a reminder:
> 
> - The internal structures are prone to change, and you don't want your 
> code to break when that happens.
> - When implementing some feature that works with projects, you generally 
> want it to work with all kinds of projects (which was the whole point of 
> project.el -- to make this approach work). And that would mean talking 
> to them through common methods, rather that examine the internals of 
> this or that project type.

I'm fine with all that, but it sounds like the above makes it impossible to
implement custom project objects, maybe because there's no make-project
method that one could use and/or subclass.