Nested needs in content of imported needs

[chrisjsewell]

As discussed in #1318 (comment):

There is a question mark over what it means to import a need with nested need directives in the content;
when the content is parsed it will, currently, process these as if they were normal directives in the project,
which will duplicate the needs (since they will likely already be in the imported need set) and ignore any modification on the needimport, like id_prefix

Essentially, whilst parsing imported need content, should any need (or needimport) directives be ignored?

[danwos]

Tough one, I see different use cases, where a different behavior is needed:

a) Import all needs on root level (also the nested ones) and therefore ignore the ones in the content.

b) Import only the "root" needs on root level (no parent link) and all nested needs re recreated as as normal (no modifications by needimport).

b) is important, if the order and structure need to be saved.
a) if modifications during import are needed.

I guess we needed an option for needimport to let the user decide how the import shall be performed.

[ubmarco]

I'd say the nested needs are the ones that follow the original structure.
I vote for ignoring all root needs that also appear in the nesting structure.
Nested needs can have a relation to their surroundings, e.g. a text that talks about what is coming below. Then the need is not there. Feels like the wrong solution.

Nesting is a form of modeling, in UML it would be a composition as the child is contained in the parent and users put it there for a reason.

Not sure however what real life projects want here. Configurable import might make sense.