Define a way how to undefine an attribute

[psss]

It would be useful to be able to undefine an inherited attribute. For example having an extra directory with helper files which should not be considered as tests. Perhaps something like this?

test: None

[psss]

Or shall we the special null value?
http://yaml.org/type/null.html

[sopos]

I faced it in the selinux [1] repo where there is attribute test defined in the root. I need to remove it for the beakerlib library.

I would not mess up with any reserved value. I would use the existing +, - notation but without a value. So

test-:

would mean to remove the attribute regardless the value(s).

1. https://src.fedoraproject.org/tests/selinux/

[psss]

So this would mean to use the special null value with the - suffix. Sounds ok. But I was thinking recently that we will need to reserve some prefix for special attributes anyway. So here's another option:

fmf_undefine: [test, path, duration]
fmf_forget: [test, path, duration]

This could be shorter than listing all attributes on separate line:

test-:
path-:
duration-:

And we could also have something like forget all inherited values:

fmf_undefine: all
fmf_forget: all

Finally, to give some more examples, why the prefix could be useful:

fmf_include: /some/fmf/identifier

fmf_include:
  - url: https://some.repo/
    name: /node/to/be/included

In this way we could reference (and graft) other fmf (sub)trees. What do you think?

[sopos]

Maybe instead of undefining we could also use replacing with an empty value test:, test-: would be special case for undefinning so fmf_undefine would work as well.

However I would prefer syntax closer to the already used. Both might be implemented though.

[psss]

Le'ts move this forward. Just ran into a use case where this would be super-needed: In the selinux tests namespace, there are tests in the root directory and thus it is not possible to store the test attribute at the top of the hierarchy and define a plan because it inherits the test attribute as well. @lukaszachy, would you agree to squeeze this into fmf-0.15?

[sopos]

but the test should be a leaf, not a node so I guess this should not happen. Like you need to create an extra leaf at the root to define a test, needn't you?

[martinky82]

I like the 'multiline' approach here. It is analogous to how the properties are (re)defined, thus IMHO it is slightly more legible for the user than a 'singleline' approach.

It might be

test-:
path-:
duration-:

or

-test:
-path:
-duration:

or, how about:

test: undef
path: undef
duration: undef

?

[psss]

but the test should be a leaf, not a node so I guess this should not happen

The selinux main.fmf in the root of the repo defines test. If we create let's say a /plans/basic.fmf it will inherit the test key and thus the node is considered to be a test. Actually it is both test and plan which is even more confusing.

[psss]

I like the 'multiline' approach here.

The problem I see with this is that it's not possible to undefine all attributes, e.g. starting from the scratch. Which would be very useful for the above-mentioned use case as well.

[martinky82]

test: undef
path: undef
duration: undef

and / or

undef: all ?

[sopos]

The selinux main.fmf in the root of the repo defines test. If we create let's say a /plans/basic.fmf it will inherit the test key and thus the node is considered to be a test. Actually it is both test and plan which is even more confusing.

I see. I think we talked about the possibility to explicitly set the object type. That would help in the contradictory cases. I could not find if there's a issue for that already, probably not.

If there's some keyword going to be used, there needs to be also a way how to use that keyword litelarly. I mean we need to define difference like this: to_be_removed: undef vs. no_to_be_removed: 'undef'.

[sopos]

I like the 'multiline' approach here.

The problem I see with this is that it's not possible to undefine all attributes, e.g. starting from the scratch. Which would be very useful for the above-mentioned use case as well.

If to_be_removed-: is ok for undefinning one attribute, what about *-: for undefinning all the attributes?
It still fits the concept of adding (x+: y) and removing (x-: y) individual values while quite self-explanatory as well.

[psss]

Looks like a nice smiley as well! :-) Pity that the * has a special meaning in yaml:

ERROR:

found undefined alias '-'
  in "<unicode string>", line 1, column 1:
    *-:
    ^

But it would be quite elegant ;-)