Re: Subprojects in project.el

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26/11/22 01:47, João Távora wrote:
>> You can use dir-locals-set-class-variables to variable like the
>> hypothetical project-subproject-prefixes to the super-project's root.
>> This contains a list of strings or regexps that identify the subprojects
>> inside the superproject.  I don't see the problem.  Elements in
>> project-find-functions would be aware of this value and proceed
>> accordingly to find the subprojects.
>
> I don't see the problem in that.
>
> I just fail to see an advantage either, given that the list of
> prefixes would be different between the "super" projects, so the
> suggestion to use a class is perplexing.

The point of dir-locals-set-class-variables is to set directly-locals
"from a distance" when creating an actual .dir-locals.el file isn't
feasible or desired.

  (dir-locals-set-directory-class "~/Source/very-big-project" 'very-big-project)
  (dir-locals-set-class-variables 'very-big-project ((nil . (project-find-prefixes "foo" "bar/baz.*"))))

Even if it's a one-use class, there's nothing wrong with that IMO. And
chances are you have multiple clones or Git worktrees of the same
project, so you may as well make it a two- or three-use class

  (dir-locals-set-directory-class "~/Source/worktree-2" 'very-big-project)
  (dir-locals-set-directory-class "~/Source/another-clone" 'very-big-project)


Of course if the user is able to AND wants to use .dir-locals.el or
marker files, that is fine, too.  I personally like the above scheme.

João