Backend tool for parsing Plugin files and extracting task function signatures

[jkglasbrenner]

Use the Python ast module to build a backend tool that parses Plugin files and extracts the task function signatures, including type hints if they exist. This information will be shown on the frontend when a user is registering plugin tasks, and ultimately will be used to construct the tasks section of the Declarative Experiment Description. The type hints can be used to figure out if new parameter types can be suggested for registration, which will ultimately be used in the types section of the Declarative Experiment Description.

Note: We want to use ast instead of importlib because we do not want to execute arbitrary code just to extract the function signature information.

Basic requirements

The general idea is that, given a plugin task function signature that looks like this,

@pyplugs.register
def init_classifier(
    model_architecture: str,
    optimizer: Optimizer,
    metrics: list[Metric | FunctionType],
    input_shape: tuple[int, int, int],
    n_classes: int,
    loss: str = "categorical_crossentropy",
) -> Sequential:
    ...

the tool will produce an output that looks like this,

{
  "name": "init_classifier",
  "suggested_types": [
    {"suggestion": "optimizer", "type_annotation": "Optimizer"},
    {"suggestion": "list_metric_functiontype", "type_annotation": "list[Metric | FunctionType]"},
    {"suggestion": "tuple_int_int_int", "type_annotation": "tuple[int, int, int]"}
  ],
  "inputs": [
    {"name": "model_architecture", "type": "string"},
    {"name": "optimizer", "type": "optimizer"},
    {"name": "metrics", "type": "list_metric_functiontype"},
    {"name": "input_shape", "type": "tuple_int_int_int"},
    {"name": "n_classes", "type": "integer"},
    {"name": "loss", "type": "string", "required": false}
  ],
  "outputs": [
    {"name": "output1", "type": "sequential"}
  ]
}

It is understood that the user will need to make modifications to the type information (content under "suggested_types" and the "type" fields under "inputs" and "outputs") before registration can be completed. The purpose for giving type suggestions is to provide initial suggestions and context that will be displayed in the frontend to help the user in this process.

The approach used to construct the "suggestion" field (lowercase, replace characters like [, ,, and spaces with underscores) may not be optimal, so alternative suggestions for how to do this are welcome. Also, this initial MVP should not try to lookup types that are already registered in Dioptra. That's something we can think about for future iterations of the tool.