lebrice / SimpleParsing

Simple, Elegant, Typed Argument Parsing with argparse
MIT License
410 stars 52 forks source link

Export args to a schema file so that YAML language servers can understand config files #288

Open RmZeta2718 opened 1 year ago

RmZeta2718 commented 1 year ago

Is your feature request related to a problem? Please describe. Currently, YAML config files are not understood by YAML language servers, and hence auto completion or type checking are not possible when editing config files.

It is really cooooool to have auto completion in yaml, right? I believe it will improve user experience greatly.

Describe the solution you'd like Provide a new API to export json schema

parser.export_schema(path='path/to/schema.json')

And then I can manually configure my YAML language server (in VSCode, for example) using schema.json

lebrice commented 1 year ago

Hey there @RmZeta2718! Thanks for posting!

This is super interesting stuff! I guess we could probably create the JSON schema from the type annotations of the dataclass fields, right? Would that be sufficient?

RmZeta2718 commented 1 year ago

I'm not quite familiar with the implementation of SimpleParsing nor with json schema. I guess most of the work is just translating dataclass fields (as you pointed out), including types, default values, required or not, etc. Besides, docstrings (and help in fields #169) can be used as description in the schema.

I would recommend filling in any possible slot in the schema, but it will be tricky to figure out all the details. For example, the type system does not perfectly match between python and json schema, I'm not sure how to reasonably convert the types. And of course, take care of enums. For complex features of SimpleParsing (like subgroups), I have completely no idea.

I think simple type annotations (directly supported types), default values and docstrings are the top priorities for things to work. I believe they are relatively easy to implement and at the same time the most attractive feature.

RmZeta2718 commented 1 year ago

I just realized that required might not be suitable in some circumstances. The required field might be specified in command line or in another file (when using multiple config files), so it's not in THIS config file and it is expected.

We might need extra params to finer control the behavior, so certain information is not included in the schema.

export_schema(..., required=False)

Or we can just ignore required, if things get too complicated.

In general, the schema should just check anything that can be checked in a single file (like types) and ignore those which need global information (like required).