useblocks
With Sphinx-Needs 6.0.0 it is not possible to use variant information on links
With Sphinx-Needs < 6.0.0 it was possible to set variants on "Sphinx-Needs element" links. With #1524 it is no longer possible.
@ubmarco: What is the work around to get it working again? Or can we enable the feature again?
The actual PR that removed the feature is https://github.com/useblocks/sphinx-needs/pull/1489. Please go through the rational for the decision.
During the implementation of strong typing, and after above PR was merged, we decided to introduce the new << >> syntax for variants.
With this I see daylight for bringing it back.
Can you please give me an example of how you used this with links / how you plan to use it with SN 6?
We are currently migrating to SN6 but this one is a blocker for us. Many of our users use variants for links.
The use case is when they define a "product" document which addresses multiple instantiations of this product in specific variations. The upward references of a need may then differ between variation.
The variant feature not being a list was an issue for us when needed to reference multiple links but we workaround it with a dynamic function. This gives a not very friendly syntax but does the work. For example:
.. need:: title
:id: 1
:upward: [[variant(var1=["up-1", "up-2"], var2=["up-3"])]]
How can we workaround this limitation for links ? Would be very nice if list were managed by variant feature, resulting in a lighter syntax than our dynamic function ^^
PS: to me the blocking point is the exception raise introduced in #1524
@David-Le-Nir thanks a lot for the detailed feedback on SN!
It would be great to have a short 30-min chat with @chrisjsewell and @ubmarco to better understand your constraints and requests. That way we can see how to align improvements with your needs.
Feel free to grab a slot here: https://useblocks.com/book-demo or just drop us a line at [email protected] if that’s easier.
Looking forward to continuing the discussion!
Let's assemble some specs how links on variants are to be used.
There are 2 ways to specify variants, both are given in the following definition:
:some_field: var_a:open or ['name' in tags]:assigned
var_a must be given in needs_variants as a key that maps to a filter string while ['name' in tags] is directly a filter string.
Some statements:
- With the new type system, I would say each variant definition needs to return the target field type.
For links it means
list[str]. - For the types
boolean,integerandnumber, the following statements are made: a. The return value completely replaces the field value. b. You can't mix dynamic functions and variants. c. You also cannot mix static text with variants.
The reason for 2 is that the + operator is not defined for boolean, integer and number. Also there is no syntax for this yet. That would be required as the field information needs to be concatenated somehow for a mix of information.
For string and list[] types I would allow the mix as we do now.
Not sure whether there is a use case to mix variants / static text and dynamic variants of type string in a single field.
In all cases we need to know exactly whether a given input is valid or invalid, so we can give users proper feedback and avoid silent errors.
To support links, I propose the following syntax:
:link_field: <<var_a:['out_id1', 'out_id2'], ['name' in tags]:['out_id1'], []>>, out_id3, out_id4
All variants returns list[str] and extend the static items ['out_id3', 'out_id4'].
So when var_a is True for a need, the final value is ['out_id1', 'out_id2', 'out_id3', 'out_id4']
When var_a is False but the filter is True, the final value is ['out_id1', 'out_id3', 'out_id4'].
If the variant default is chosen the final value is ['out_id3', 'out_id4'].
That syntax should be safe to parse. @chrisjsewell any objection to this? Any other feedback?
Edit: Another option is to remove the quotes and go with
:link_field: <<var_a:[out_id1, out_id2], ['name' in tags]:[out_id1], []>>, out_id3, out_id4
So the syntax would be like for normal link ids. Only concern I have is escaping. If that syntax is applied to extra options of type list[str] and the field value has a comma ,, we need an escape sequence.
Related issue from the time before strong typing was introduced: https://github.com/useblocks/sphinx-needs/issues/915