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

[Dmitry Gutov <dgutov@yandex.ru>]

On 25/11/22 21:45, Eli Zaretskii wrote:
>> Date: Fri, 25 Nov 2022 19:24:26 +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>
>>
>> On 25/11/22 09:30, Eli Zaretskii wrote:
>>> I'm probably missing something: how does a Lisp program construct an
>>> instance of a project with a known backend?  For example, if the project is
>>> of the 'transient' kind, how would such a Lisp program go about constructing
>>> an instance without exposing/knowing about the internals of the project
>>> object?  I see no generic make-project API that such a Lisp program could
>>> call.  What did I miss?
>>
>> 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.

No, again, he just wanted to show a quick example. With pseudocode, 
almost like.

>> The program that creates instances of 'vc' type is called
>> 'project-try-vc'. But we could similarly add a generic method belonging
>> to the same unit of code (called 'project-subprojects') which would
>> "belong" to the VC project backend and create a list of instances of its
>> type.
> 
> 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.

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

In most cases we will say it's not a good idea, but when a practical 
goal is described we will decide to either say "go ahead, it's okay in 
this case", or, hopefully, suggest a different way to reach that goal 
(just like I did with the 'project-parent' definition example). Or 
rethink and throw away the whole design (hopefully not).

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.