node referencing and inheritance about fmf HOT 9 CLOSED

I am not sure this is the best idea, from point of FMF this seems quite bad. You are basically breaking the tree structure, where some leaves belong to a branch but do not take anything from it, instead they are virtually moved to different branch.
So what prevents you from moving those tests where they actually belong and keep the inheritance sane and intact?

from fmf.

I don't think we should introduce complex referencing like suggested here. At least for now. This would/could lead to many non-trivial implementation problems and would make understanding how data are inherited much harder. I can imagine we introduce some kind of plugins to support special/common scenarios (such as auto-generating directory path for beakerlib tests) but in the fmf core I would like to see only the very essential features. Among these I also count adding attributes with + as this is related in a straightforward way to inheritance which, of course, is at the very core of the fmf concept and it would definitely not make any sense to leave this on an external tooling.

from fmf.

solved with own implementation in COLIN project.
In case similar implementation will be incorporated to some FMF extensions, plugins, I'll be very happy :-)
see implementation for inspiration, it is very straightforward and clean:
and allow do meta plans, could be named "FMMF" - flexibile meta metadata format @psss ;-)
https://github.com/user-cont/colin/pull/141/files#diff-5eb57703ea0cb920089bd5ddef755c6fR19

from fmf.

my case solved by: #36
I've decided to solve it as postprocessing step, because it could be easier to find that base objects are constructed already

from fmf.

@jkrysl Tree structure is not broken, just one thing what is chaged is that these data elements are inherited from reference, not from parent items and also copied sources, so that easy to debug this.
But I understand you PoV.

My usecase is, that someone, wants to create virtual hierarchy based on some existing one.
(maybe could be used for linking (merging) test coverage with real cases)

see also real life example in PR

from fmf.

+1 to @jkrysl; this seems risky at best.

If you have some project-specific mapping, that's fine (most if not all projects will have some own rules), but you should always do that on project-specific tooling. Maybe I'm not understanding what you mean, but it seems like something you should write your own tools for that; FMF should really be just about discovering and collecting plain data -- not giving meaning or semantics.

from fmf.

And by the way, what if I want to have key with @ in it?

from fmf.

@AloisMahdal

• No,it is not project specific, it is generic, but inspired by one project what has similar tooling. And This is PoC how it can work.
• No, it is not possible to implement it on project specific level, because there is already semantics with + char what is removed and I'm not able to postprocess it without changes inside. so that I cannot implement it and reuse there this semantics for + to keys
• Yep it is possible to let FMF as plain tool for collecting data and all other stuff let in other projects or at least in some another tools what are part of FMF, but in that case we have to remove all semantics in FMF like + handling, and also remove this data inheritance, and implement it in another tool, because actual solution leads to info merging, so unable to reconstruct original data.
• I would like FMF contains some common solutions for common items, and in case you would like to do it in your way, you can use simple data and generate your own solution.
• I can also imagine, that there will be some common transformation templates for our common work, like for beakerlib, for avocado, for STI, like formatting like {}/{}/{} (root, path or name, test)
• So that possible solution is also, that these functions are not enabled by default, and could be enabled and are part of Tree methods. or via some plugins or modules, what can be added to FMF.
• And your last question. I've also thought about that, if it is good idea or not, probably could be and probably we can be inspired by xpath solution. But as simplest solution I've just choosed this whole node inheritance as the most common case for referencing. and with + semantics you can modify it nicely. just one think what is possible to do it with @ in keys is renaming of one attribite to another, or inherit data from more nodes by keys.

from fmf.

Good to hear the current FMF implementation is extensible enough for your use case. We can revisit the concept of plugins later.

from fmf.