project terminology

[Stephen Leake]

Eric Ludlam <address@hidden> writes:

> On 08/11/2015 04:01 PM, Dmitry Gutov wrote:
>>
>> * I wonder what's the main use of having hierarchical projects vs.
>> simply tracking several currently open projects (or project roots).
>> And how the consumers of the API would take advantage of that
>> distinction.
>>
>
> I doubt consumers of the project API would care.  Nested projects is
> simply something the detection system should enable.  

I'm puzzled by this terminology; I don't think "nested" means the same
thing as "hierarchical"; nested is a subset of hierarchical.

For example, here are two possible project layouts on the disk:

layout 1:

/core
    # math and IO utils

/my_proj
    # project file includes dependency on /core


layout 2:

/my_proj
    # no dependency in project file
    /core
        # math and IO utils


Other than the layout change, the code is the same (the build scripts
that specify paths etc are slightly different).

I would call both of these "hierarchical", but only layout 2 is
"nested".

Apparently, the term "subproject" is also appropriate for core in layout
2.

In any case, it would be good to have the option to treat "my_proj" as a
single project, that "includes" "core" in any operations that involve
searching for things in "the current project".

As for distinguishing hiearchical from a simple set of open projects,
that's what the project dependency declarations are for. They don't
necessarily need to be visible to project.el; some backends may handle
that entirely on their own (the Ada mode backend does, for example).

> A system that needs to load lisp
> code needs to protect against ill formatted lisp code.  Putting this
> in a core system will help implementations from all creating the same
> latent bug.  If project.el isn't going to provide detection services,
> then it won't need this feature.

There is a difference between detecting the presence of a project, and
using that project.

An extremely simple way to detect projects is to ask the user to specify
a project location. Another way is to look for a special file name.

Once the project file is found, then it must be loaded. But the
detection step (whether ask user or some other method), does not require
loading the elisp file (or parsing the project file in general).

In the above, I've assumed "project detection" meant "deciding whether
there is a project in a disk directory".

In other circustances, "project detection" means "pick which of the
available projects is appropriate for the current action".

It's not always clear from context which meaning is meant. Perhaps we
could use the term "project selection" for the latter.

In project.el, project-find is used for project selection, but the
current implementations of it do project detection as the selection
algorithm. Other choices are possible; the "project-explicit"
implementation I proposed separates detection from selection.

I think EDE is similar, in that it tends to use project detection as
part of the selection algorithm.

-- 
-- Stephe