I see the potential for having an abstract OpenApiGeneratorNameField that is common to all codegen implementations and then extended in each of them narrowing down the possible values while providing also a default.

Something like:

´src/python/pants/backend/openapi/codegen/extra_fields.py`:

class OpenApiGeneratorNameField(StringField):
    required = False
    default: ClassVar[str]
    value: str

src/python/pants/backend/openapi/codegen/python/extra_fields.py:

class PythonOpenApiGeneratorNameField(OpenApiGeneratorNameField):
    alias = "python_generator_name"
    default = "python"
    valid_choices = ("python", "python-pydantic-v1")

Similar thing for the Java codegen as apparently there are new (beta) generators available.

The reason I'm suggesting this is because nothing is that like it's been implemented, nothing is stopping an end user for typing python_generator_name="rust" or simply misspelling the value, which would lead to an execution error that may be hard to decipher.

This has the obvious consequence of having to update the list of valid choices for each codegen when new ones are available, which can be a PITA.

A way to prevent having to update our sources would be to instead have a validation rule that obtains the list of all supported generators from the tool, the command openapi-generator list -s should return such a list in a comma-separated list.

nothing is stopping an end user for typing python_generator_name="rust"

I don't think this is the problem we need to solve. Similarly, one could use python_sources(sources=["*.rs"]), we don't want to validate such a thing. Moreover openapi-generator list doesn't tell us which language it generates, which makes sense because the generator can actually generate multiple different kinds of files, like .py, .txt, .yaml. Anyway, the validation will create more problems than it will solve.

simply misspelling the value

Yes, this is a good idea, we can use openapi-generator list for simple set validation.

Added validation with OpenAPIGeneratorNames

Moreover openapi-generator list doesn't tell us which language it generates

I rather take it more like the generator targets a language + tooling, it does generate support files that are not in the target language, this is because it aims at generating a self-contained buildable product. And this isn't 100% correct either as it also can generate docs and Apache httpd configuration files so I understand that hardcoding an assumption into their naming convention could be problematic. Anyway, at least validating that the chosen name is an accepted one before running the tool gives a better UX.