I want a Plugin root key and schema

[cvchaparro]

As a plugin developer, I want a dedicated root key and schema for defining plugins, so that I have a clearer and more explicit definition of what my plugin does.

AC:

• In the core spec there is a new schema defined Plugin
• In the core spec, root keys defines a new entry plugin with the new Plugin type
• There is a new PluginContributions enum which provides a list of enums for each of the plugin contribution types.
• There is a new schema PluginCommand that has the following fields:
  • Group - A string indicating the command's group name
  • Input
  • Output
• The new schema Plugin has the following fields
  • name - The name for the plugin
  • commands - An optional list of Behavior entries
  • additional_definition_resources - An optional list of files that contain the plugin-provided definitions
  • primitive_validations - An optional list of primitive-type validators
  • definition_validations - An optional list of definition-type validators
• The Gen-Plugin plugin is updated to use the new schema
• Existing plugins have their definitions updated

[cvchaparro]

I've come across another place where I think this Plugin schema will allow us to enhance our plugin definitions.

The specific example comes from the list-plugins command which only has optional arguments (i.e. --all, --active, and --inactive) but requires at least one option to be provided. As it currently stands, if no option is provided, we proceed to delegate to the command as opposed to displaying the command's usage because we don't have a way to distinguish between a command where all arguments are optional and the case where the command has only optional arguments but at least one is required. Currently, this is the only plugin command we have that has this constraint but I can easily see it being necessary in for future commands, as well.

My suggestion would be that we change how we define the commands field so that it is an optional list of CommandBehavior entries (or some such structure extending Behavior) where one of the fields in CommandBehavior is whether at least one argument is required. One option could be to make this an optional field whose value automatically defaults to whatever value is most common (probably True) and is set to False for commands like version, etc that don't require any arguments.

[jondavid-black]

The plugin scheme needs a field to allow for new schemas and extensions to be defined as well. At least for my use cases, one of the most common needs is to establish a schema to extend existing AaC or create new domain specific model definitions.

[Coffee2Bits]

Looks good. Instead of the helper IO and IO2 modules, can we rename IO -> IO_DEP and IO2-> IO?

[Coffee2Bits]

Looks good. Only change would be to use enums to select the Temp file mode instead of strings.

[Coffee2Bits]

Great work!