salotz

Ahhh the only place this shows up is in the github issue URL haha: ``` Crash: jsonSchema must be a valid JSON Schema with type=object or reference ```

``` { "type" : "object", "properties" : { "build" : { "type": "string" }, "name" : { "type": "string" }, "file" : { "type": "string" } } } ``` Going...

https://github.com/Tinche/uapi/blob/main/src/uapi/openapi.py#L63 I understand why Literal kind of makes sense here, since you only want a singular value of the enum, I am beginning to think its not really the intended...

That explains the intended usage of that :) Partially I just wasn't sure what to expect and since string types got serialized into strings I thought maybe the integers etc....

I very much agree. It would be great to have optimized marshalling that leverage types. I guess my only issue then was that in this module there was only the...

> In the mean time, you can probably dump the schema straight to JSON and load it back up with a json library - that will probably get you the...

A banal concern but internally I am using the code name `scattrs` for this module. And will propose this as the name for it going forward. I considered `schattrs` but...

I like this. I've found myself reaching for attrs metadata a lot to do particular customizations but this doesn't work for basic types like `dict` etc. which I've found would...

> If you still want this feature, I guess pydantic supports it, but you'll have to change your attrs classes to pydantic.BaseModel. There is a big difference in the proposed...

@diego-oncoramedical The problem I see with your example is that there is no specialization for different converters. Should you always rename a field? Or only for JSON output? For instance...