[enhancement]: enums for node inputs

[keturn]

What should this feature add?

I defined an enum like so:

Datasets = Enum("Datasets", ((s, s) for s in list_available_datasets()), type=str)

and it shows up okay in /docs:

[excerpt from the invocation's section in /docs]

Markov Name Data Loader

description:	Load data for the Markov Name Generator.
id*	Id[...]
is_intermediate	Is Intermediate[...]
workflow	Workflow[...]
use_cache	Use Cache[...]
name*	string - title: Datasets - input: any - ui_hidden: false - An enumeration.Enum:[ religions, cities_worldwide, pokemon_modern, snakes_common_names, english_towns, breakfast_cereals, … ]
type*	Type[...]

but the field doesn't display as an input on the node editor. the browser log says

Skipping unknown input field type

Alternatives

We can also use "Literals" for the purpose of giving OpenAPI a list of permissible values:

Datasets = Literal[tuple(list_available_datasets())]

but I feel like using Python's provided Enum constructor is a less hacky approach than giving a non-literal initializer to Literal.

and enums should work according to https://docs.pydantic.dev/latest/usage/types/enums/

[psychedelicious]

I strongly prefer proper Enums but there are some pros to Literals.

When working with serialized data, there's extra fanagling - you have to do MyEnum.value == some_string or try: MyEnum(some_string) to check if your value is valid. Literals are simple equality checks. Of course this can be abstracted away. I've done so in invokeai/app/util/metaenum.py.

There's also extra fanagling with OpenAPI.

Here's an Enum and a Literal in schema form (snippet from a larger schema):

{
  "properties": {
    "my_enum": {
      "allOf": [
        {
          "$ref": "#/components/schemas/TestEnum"
        }
      ],
    },
    "my_literal": {
      "title": "My Literal",
      "enum": [
        "red",
        "green",
        "blue"
      ],
      "type": "string",
    },
  },
}

The Enum is a pain. You get an allOf with a list of references to other schemas that the value must conform to. In this case, it must conform to TestEnum, but there could conceivably be any number of references in that list.

To get a simple list of allowed values, you have to traverse the schema to locate the reference schemas (btw schemas can be nested arbitrarily), get all the values from all the schemas in the allOf, merge them, figure out what type represents all of them at once, and so on.

With the Literal, you get the valid values directly (and the schema even says "enum").

Now take a look at TestEnum schema itself:

{
  "title": "TestEnum",
  "enum": [
    "1",
    "2",
    "3"
  ],
  "type": "string",
}

It's exactly the same schema as the Literal.

If we weren't manually parsing an OpenAPI schema to generate node templates, I'd be all for python Enums everywhere. But parsing out the references gets pretty hairy and python Literals make it trivial by literally skipping a load of unpleasantries related to dereferencing the OpenAPI schema.

Literals are also arguably simpler to define.