Version 0.2.0 (For utoipa v5)

[DenuxPlays]

Things that break our implementation:

• Real generics
• Automatic Schema Collection (maybe?) & Auto collect schemas recursively from usages juhaku/utoipa#1065

I am not sure if the second thing really does break uotipauto but we could reduce compile times if we can somehow filter out what is already collected by utoipa.

Our issues that we need to fix:

• Feature generic_full_path is not able to parse all imports #43 not needed in v0.2.0 anymore

[DenuxPlays]

@ProbablyClem I wouldn't actually change how many things are detected. (If it does not break anything).
Because it would add a lot of complexity for almost none advantages.

We would still have to loop through the files so no compile time advantages there.

What do you think?

[ProbablyClem]

I agree
It's nice to see utoipa advance !

[DenuxPlays]

@ProbablyClem
Hey,
as the mainter of utoipa pushes more features I think we can get rid of like 75% of this crate.
I guess thats the goal is, so that only paths will are needed in the openapi definition and the rest is getting discovered by utoipa directly.
ATM I would completely remove generic schema discovery and put schema discovery behind a feature flag (as I guess their are still usecases where schemas are needed but not listed in any paths macro).
I think that we can do the same with responses but currently utoipa does not support auto-discovery of responses.

Just wanted to check in with you maybe you have other/better ideas or anything you want to say.

[ProbablyClem]

The goal of this crate is to provide what's missing in utoipa, but ideally it'll be useless once utoipa figured it all out.
We can remove what's been added already 👍