search

NiceAesth / aiosu

Simple and fast asynchronous osu! API v1 and v2 library
https://aiosu.readthedocs.io
GNU General Public License v3.0
15 stars 3 forks source link

[pydantic] `v2` Breaking changes #149

Closed NiceAesth closed 1 year ago

NiceAesth commented 1 year ago

Pydantic v2 has recently been released, and introduces many breaking changes. Since this library is one that the user might potentially be using in their own project as well, I am unsure about how to proceed regarding whether to migrate to v2 yet or not. Would appreciate some thoughts on this.

Migration would result in significant performance improvements, at the cost of requiring people to migrate their own projects to pydantic v2 if they are also using the library (or at least change imports to pydantic.v1 as the library still provides those)

If I proceed with migration, relevant libraries such as aiordr will also be migrated to v2 alongside everything else.

Relevant: https://docs.pydantic.dev/latest/migration/

NiceAesth commented 1 year ago

CC'ing major users of the library: @7mochi @mayacopeland @cmyui @tsunyoku @aticie @tobycm

tsunyoku commented 1 year ago

i'd suggest moving to v2. big libraries like fastapi have already done this (and caused some issues with bancho.py, heh) and i think as a result the majority will migrate to v2 anyway. also, most people using aiosu probably aren't using it in a way that upgrading to v2 will break their own code

also not to forget that bump-pydantic exists, if someone does need to migrate their code it is very easy. i think we should move forward. it's only time before v1 will be deprecated anyways

efehana commented 1 year ago

I agree with the migration to v2, I have already upgraded it on most of my projects.

cmyui commented 1 year ago

LGTM also most of the backwards incompatibilities i've run into from this upgrade are related to more complex feature use (e.g. generic models) which most users probably won't run into

NiceAesth commented 1 year ago

LGTM also most of the backwards incompatibilities i've run into from this upgrade are related to more complex feature use (e.g. generic models) which most users probably won't run into

I was a bit upset at the removal of parse_raw and parse_file, but I guess I will simply reimplement them as they were quite useful with how the library was structured

NiceAesth commented 1 year ago

Thanks for the feedback, I will start work on a separate v2 branch for now.

tobycm commented 1 year ago

nice thanks for the CC too