replicate
Switch kin-openapi to libopenapi
Sadly, libopenapi doesn't discover the invalidness of https://github.com/replicate/cog/blob/main/test-integration/test_integration/fixtures/invalid-int-project/predict.py
I think it's okay to delete that test case. It's a pretty rare case, and wouldn't be hard to upstream a change to libopenapi to handle that case.
@yorickvP could you describe in a bit more depth why we need to switch to libopenapi? It's not obvious to me.
This comment contains a summary: https://github.com/replicate/cog/issues/1186#issuecomment-2011832395
We could try to get away with kin-openapi, that would just require fixing the test for the version in https://github.com/replicate/cog/pull/1552
We use kin-openapi in the api repository to process the schemas generated by cog models, and I would probably want to see us using the same code both here and in production.
What is actually wrong with kin-openapi?
What is actually wrong with
kin-openapi?
No OpenAPI v3.1 support: https://github.com/getkin/kin-openapi/issues/230#issuecomment-1002659224
However, it seems we happen not to use any of the unsupported 3.1 features. Would be good to check somehow.
Our own API's spec is 3.1, and we use kin-openapi to validate it in the api codebase. Is the lack of official 3.1 support actually causing us any problems?
Here's a list of changes: https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0 . My concern here is that these schemas are generated from user input by pedantic, so we don't necessarily control it when they break.
The thing we should mainly test is exclusiveMinimum (pydantic's gte).
Closing in favor of #1687, which rewrites the OpenAPI 3.1 spec version emitted by FastAPI to OpenAPI 3.0.
