How to correctly implement plugin support where each plugin has its own options?

[alexanderfast]

In my case plugins are dynamically loaded from other assemblies, each plugin supplies its own options instance and the entire commandline is parsed once for each plugin. This requires IgnoreUnknownArguments to be true, since each parsing must be able to handle arguments intended for another plugin.

Because of the way IgnoreUnknownArguments is implemented this becomes a problem. It assumes that every argument has a value, so if an unknown argument is in fact a bool the next key is swallowed offsetting the rest of the parsing by one. In the example below, Bar gets no value and its value is added to the value list instead.

Is there a way around this? Or is there a better way to approach plugin support?

public class OptionsPluginA
{
    [Option("bar")]
    public string Bar { get; set; }

    [ValueList(typeof(List<string>))]
    public IList<string> Values { get; set; }
}

public class OptionsPluginB
{
    [Option("foo")]
    public bool Foo { get; set; }
}

class Program
{
    static void Main()
    {
        var args = "--foo --bar bv v1 v2".Split(' ');
        var parser = new Parser((ParserSettings ps) => { ps.IgnoreUnknownArguments = true; });

        var optionsA = new OptionsPluginA();
        parser.ParseArgumentsStrict(args, optionsA); // Bar = null, Values = bv v1 v2

        var optionsB = new OptionsPluginB();
        parser.ParseArgumentsStrict(args, optionsB); // Foo = true
    }
}

[nemec]

I think the only way around this would be to change the behavior of IgnoreUnknownArguments to not consume a value but unfortunately that leads us to another issue: if it's unknown, how do we know whether or not the option consumes a value? If it does and we don't, extra values are dropped into the ValueList.

This seems like an impossible scenario to fix given that all options are determined with attributes at compile time. With a fluent interface, you could dynamically load your plugins and then configure everything at runtime but this library doesn't have one of those.

[alexanderfast]

The strategy of enhancing the way unknown arguments are ignored was discussed, but we reached the same conclusion. It's an unsolvable problem as long as we can't determine if the option consumes a value or not.

The wiki has a page proclaiming that the library is "plugin friendly". But it relies on the user telling the program which plugin (essentially which options class) that should be used for parsing. Something that Verbsstarted to cover very well. Now that I think about it, maybe that wiki page should be written, implementing plugins as verbs.

But it doesn't cover our case. We can't rely on the user to specify which plugin to use. More often than not, we use all of them. We are currently investigating if there is a way to take all option classes (from the plugins) and concatenate them dynamically. Then use this superset of options for parsing. It won't support two different plugins having the same name for an option but different types, but that is acceptable.

I'm trying to determine how much work this would be, it changes a lot since this dynamic option class would no longer have decorated properties you write to. It will be something else.

What's your take on plugin support at large? Yay or nay?

[nemec]

I fully support the plugin idea. It may get complicated, but maybe the spec could be augmented to also reference the Option instance that will be passed to the reflection helper when setting a property. That way, you could easily integrate multiple Option classes (one for each plugin) into the spec without a lot of extra work internally.

One challenge would be finding a way to access those individual instances, with their properties set, in a type-safe way, once parsing is finished.

[alexanderfast]

Hm, I'm afraid I fail to see how that would work. If you find the time, could you please elaborate?

[nemec]

It's been a while, but I think it was something along these lines:

• The spec is essentially the full configuration of CommandLine - which parameters are mapped where, how, and what types they should be.
• The spec is, essentially, a collection of Specification objects.
• The Specification object doesn't contain any reference to the class the Option/Value belongs to. For example, if I gave you the specification to one of the following classes, how would you tell which one it belongs to?

class OptionA
{
    [Option("name")]
    public string Name { get; set; }
}
class OptionB
{
    [Option("name")]
    public string Name { get; set; }
}

• The idea here is that we inject the class (or better yet, the instance) into each Specification object so you have a reference to the original.
• Given that, each "Plugin" will become its own independent option class. The spec then becomes the union of the main Option Specification and any plugin Specifications. Kind of a mixin system. E.g.:

class Option
{
    [Option("name")]
    public string Name { get; set; }

    [Option("age")]
    public int Name { get; set; }
}
class VerbosityPlugin
{
    [Option('v')]
    public bool Verbose { get; set; }
}

// This is generated by reflection
var spec = new[] {
    new Specification("name", option),
    new Specification("age", option),
    new Specification("verbose", plugin)
};

• Then, during parsing when you match --verbose to spec[2], you can use reflection to set the right property on the right class. Of course, as the app developer you will now need to manage the option class as well as any plugin classes. Since C# doesn't have multiple inheritance, I don't think it's useful to make the Option class inherit from the Plugin (to get both sets of properties in one class). Maybe instead you could embed the plugin as a property within the main Option class, with a new PluginAttribute. Instead of creating a sub-command like with verbs, it would instead "merge" the plugin options with the main options during parsing.