You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the doc states it here, the composite requirements have not received enough development until now because no one requested this strongly enough.
Could you describe your use case and whether you need to work with composite requirements strongly? Just implementing the JSON export should be pretty easy, the question is if you are intending to use this feature in general.
One recent idea that I had about this was to merge Section, Requirement, Composite Requirement into just ONE node and that node would be controlled with a grammar as to whether this node is composite or not. Unfortunately, doing this seemingly easy change would require a pretty massive refactoring of the codebase which I would not initiate until there is a really strong need.
I don't have a strong need of using composite requirements. There are perhaps two instances of composite requirements which can be avoided. So there is no need to rush any decision on this.
Hey @fniu, just a heads up: I have other reasons to improve the composite node support. @mettta and I have started working on an incremental migration here: #2193. In a few days / weeks, we should be able to implement the JSON support as well.
A spoiler: The composite nodes will have a new syntax: [[NODE]] ... [[/NODE]]. The COMPOSITE_... will be removed from the grammar eventually.
Describe the bug
Composite requirements are not included in the JSON export. It is simply exported to an empty dict {}.
The text was updated successfully, but these errors were encountered: