Support metadata based CLI: was Demo/test case: TaskRunner parsing

[jzabroski]

Imagine an exe called TaskRunner.dll that has a bunch of TaskDefinition<T> sub-classes.

I would like to provide dotnet-suggest support for each one. To do this, I would need to load, using reflection, an instance of each TaskDefinition and be able to explain to System.CommandLine how to use this metadata to provide command line auto-completion suggestions.

public interface ITaskDefinition { string Key { get; } }
public abstract class TaskDefinitionBase<T> : ITaskDefinition where T : ITask
{
  public abstract string Key { get; }
}
public class CleanFullTaskDefinition<T> : TaskDefinition<CleanFullTask>
{
  public override string Key => "cleanfull";
}
public class SqlExecuteTaskDefinition<T> : TaskDefinition<SqlExecuteTask>
{
  public override string Key => "sqlcmd";
}
public class FluentMigratorTaskDefinition<T> : TaskDefinition<FluentMigratorTask>
{
  public override string Key => "fm";
}
// etc, 1,000s of tasks to build Gilles Tréhin's Urville :)

[jonsequitur]

This should be pretty straightforward. Argument.AddSuggestionSource can be used to provide dynamic suggestions via a delegate or via your own implementation of ISuggestionSource.

Depending on how many tasks there are and whether the scan will be costly, you might consider doing this reflection only once and caching it, e.g. creating this index at build time or writing a file to disk after the first scan.

[jzabroski]

Thank you, Jon. Would you accept such a demo as a PR? Basically, the direction I want to go with this is to replace MSBuild entirely with dotnet.exe.

…

On Sat, Mar 16, 2019 at 12:37 PM Jon Sequeira ***@***.***> wrote: This should be pretty straightforward. Argument.AddSuggestionSource can be used to provide dynamic suggestions via a delegate or via your own implementation of ISuggestionSource. Depending on how many tasks there are and whether the scan will be costly, you might consider doing this reflection only once and caching it, e.g. creating this index at build time or writing a file to disk after the first scan. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#461 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbT_TtEnRxfMqd4oeh7VlwcVaXLqwN5ks5vXR25gaJpZM4b3ehn> .

[jonsequitur]

I would be happy to look at the code and help work through the use case. This sounds like it falls under the general category of app models that sit on top of the core functionality and we want to enable scenarios like this but building the app models themselves isn't the general goal of this project so a separate repo would be best.

[jzabroski]

Thank you, Jon! I somewhat agree, but the problem with splitting these things out into separate repos is you lose the benefits of ReSharper refactoring things and so the downstream maintainers get stuck with double (or more) of the work. I also think a "plugin of plugin" model is a fairly realistic scenario, in that every job I've ever worked on has needed some command-line tool to orchestrate tasks. It would just be unique in the sense that it's turtles all the way down: You plug in your TaskRunner plugin into dotnet.exe tools, and you plug-in Task plug-ins into TaskRunner. (MSBuild just happens to be a special case where the Tasks are build related rather than problem domain related.)

In effect, what this demo is really demonstrating is how to build a W-grammar/attribute grammar using System.CommandLine: each Task implements its own context-free grammar via the Argument.AddSuggestionSource (if I understand it correctly - I'll try to prototype this weekend.)