Intended usage and behavior of PluginOpt val_type when set to a list, or list of types

[TrevorBenson]

I'm opening this as Q&A to get a deeper understanding of the PluginOpt val_type intended usage. I'll describe some behavior I've noticed as well which I suspect has been acceptable, but possibly unintended.

Intended use of val_type=[list] or val_type=list

At first, I presumed that val_type of list might be a method for PluginOpt splitting strings on : as it was suggested for a delimiter in the How to Write a Plugin page, which got me to investigating PluginOpt to determine and try a few tests.

So far I've been unable to determine how to properly use a Plugin as a val_type of list. I can use it if I set it to multiple types, like [bool, list], but if I try to set it to only a list any use of option foo seems to lead to various errors. Maybe I've just not found the way to set the default= parameter and any associated -k plugin_x.foo= syntax.

Reading the set_value function it doesn't address a type of list, so it's quite possible I just was thinking of how it might be used vs. its actual intended usage.

Behavior where enabling a plugin can become truthy, but no longer a boolean.

I was designing a plugin with a mix of val_types for bool and str, then splitting on : for a list of values. Then I ran into some logic that didn't work which only took a couple of minutes to track down why. However, got me wondering if it was intended, so I will include it just for clarification in this discussion of PluginOpt in case it helps future plugin writers.

Let's say there is a plugin defined as:

class PluginX(Plugin, IndependentPlugin):
    short_desc = "Plugin X"
    plugin_name = "plugin_x"
    option_list = [
        PluginOpt(
            name='foo',
            default=False
        )
    ]

• The PluginOpt val_type is bool, inferred from default being False.
• When enabled via sos report -o plugin_x -k plugin_x.foo foo is set to True and the val_type is bool.

However, when a plugin sets

PluginOpt(
    `name='foo',
    default=False,
    val_type=[bool, str]
)

• After being enabled via sos report -o plugin_x -k plugin_x.foo foo is set to 'True' with a val_type not of bool, but str.

It occurs in the set_value function and even contains a comment regarding it:

    def set_value(self, val):
        # 'str' type accepts any value, incl. numbers
        if type('') in self.val_type:
            self.value = str(val)
            return
[...]

It doesn't cause any bugs of course because it's "truthy" for if self.get_option('foo') checks. I could see where having it remain a bool could provide a minor benefit when writing a plugin, at least when the class docstring eludes to the type being inferred from default as it might not be obvious it would change types in this specific case.

Thanks in advance for any responses to clarify the intended usage and behavior of the PluginOpt val_type!

[TurboTurtle]

I'm reaching way back here in memory, but I think this may have been a shortcut on "true analogous" strings, e.g. yes or on to enable boolean toggles. I could definitely be wrong here though.

Overall, val_type is meant as a soft gating for type validation, since we can't really rely on argparse to do type validation for colon-delimited values, as it will cast all of it to strs and we need to slice-and-dice that ourselves.

Cards on the table, it's been a while since it was implemented, and I wouldn't be surprised if there's a gap in the logic. Certainly no red tape on making changes to PluginOpt or any of the validations we do for it.