Re: Subprojects in project.el

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29/11/2022 11:56, João Távora wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> But I'd be happy to find out that 98% of our users' cases can be
>>> handled with markers.
>> I think you'll begin to lose that bet right here in the Emacs repo.
>> Take the doc/ directory where Emacs's manuals live.  It's pretty
>> reasonable to consider a non-programmer (or non-Elisp) contributor
>> working on that directory almost exclusively, perhaps as a proof-reader.
>
> Setting aside the artificial nature of this example, they could add
> "lispintro" or "lispref" to project-vc-extra-root-markers and have
> that nested project recognized.

Talk about artificial.  I don't want to say that "lispintro" or
"lispref" anywhere in my filesystem marks the doc/ subproject.  I might
have identically named elsewhere.  And these are much more likely to
change than doc/ won't.  In other words, it's not correct to describe a
subproject in terms of its interior structure.

And there's also the obvious drawback, that you yourself raised, that
looking for marker files is needlessly taxing in terms of file system
operations.  Especially, as you highlighted, under TRAMP or a
slow-to-access file systems.

> As long as the directory contains at least some unique (in the scope
> of the containing project) file or directory, the marker-based
> approach can work fine.

That's not what marker files are good at.  Markers, like the .git
directory, are great for identifying many projects whose root location
is not easily predictable but which have a very stable file element at
their root at all times.

But they're _not_ great for designating a fixed and easily predictable
subset of hierarchies in a within a more complex, longstanding, legacy
hierarchy.

> I don't know how many people actually intend to do what you described,
> though. But it seems workable just the same.

Whoever wants to reap the benefits of subprojects for NPM packages in a
monorepo with marker files will probably come across situations where
they want to reap the same benefits for fixed directories but without
marker files.  And vice versa, of course.  The solution to be adpted
should not favour marker files over other approaches.  And it's so
simple not to incur in this design mistake that's it's a bit baffling
that you keep insisting to do it.

João