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?

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.

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).