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

[Dmitry Gutov]

On 02/12/2022 16:16, Eli Zaretskii wrote:
> > Date: Fri, 2 Dec 2022 03:32:42 +0200
> > Cc: monnier@iro.umontreal.ca, danny@dfreeman.email, eric@ericabrahamsen.net,
> >   emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > Still, if you do want to inherit from 'VC-aware', we can make a public
> > constructor for it. Probably after Emacs 29 is released, and we can see
> > that the structure is settled (it's looking this way now).
> >
> > As for 'transient', well, the constructor can be added as well. The
> > structure is stable and least likely to change; unless we just make an
> > executive decision to turn them all into structs or whatever. I just
> > didn't want to encourage people using it -- even Joao's usage is odd
> > because he not only calls the 'project-root' function, but also
> > 'project-files', and it's just luck that its behavior suits his current
> > goals.
>
> I'm just surprised that a simple request to be able to create a project type
> that is not one of the 2 built-in types is not answered by a simple "use
> this and that APIs".  project.el strives very hard to be generic, but what
> is the use in doing that if extending it by 3rd-party code is so
> complicated, and on top of that is not already available?

But that's what defines a project type: its implementations of the 
generic functions.

> So yes, I think we do have public constructors and whatever else could be
> reasonably needed if one wants to subclass either of the two built-in
> project types.  For this purpose, I don't think it matters how rich the
> built-in type is -- that is something for the sub-classing application to
> worry about.  We just need to give them enough rope, and leave the rest up
> to them, IMO.

FWIW, the built-in types's structures have been fairly stable for a 
while. So for most practical purposes people should be able to "extend" 
them already, definitely if it's for personal use. But for public use as 
well, if the package author is willing to provide prompt updates in the 
case of potential (rare) breakage.

I just rather hear about actual cases or intended scenarios, to decide 
how to support them better. E.g. providing constructors will "stabilize" 
some stuff, but won't make things much easier, coding-wise.