-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade dependencies, most important to utoipa 5, dropping a bunch of workarounds #947
Conversation
In order to ensure we process all the settings fields, we destructure them.
bb84d08
to
aa3b4a7
Compare
@chirino @carlosthe19916 not sure this has an impact in the UI side of things. |
aa3b4a7
to
f06e4d1
Compare
I can see the openapi.yaml will change a bit. I don't see too many changes though (it is something I can manage). I think it should not be a blocker for the UI. So those changes should be fine |
f06e4d1
to
6eca0c5
Compare
6eca0c5
to
22a2739
Compare
By leveraging utoipa_actix_web, this change removes the hand-crafted collection of openapi operations, and let utoipa collect this during the creation of the actix web `App`. This results in the actual spec, and removes the need to keep this aligned with the `openapi` functions we had. The downside is, that the `xtask` now needs to construct a full `App` instance. Which isn't a big deal, but requires an embedded database to the instantiated. However, we do this for running tests too. This also already fixed an missing operation.
@jcrossley3 I'll work through the comments. In the meantime, I pushed some more changes. Which gets rid of the manually collected openapi spec altogether and uses the actually registered handlers to construct it. |
This updates a few dependencies. Most notably to utoipa 5, which now supports nesting of specs, and generic type arguments. Allowing us to drop some workarounds we had in place. It also auto-collects schemas now.