strawberry-graphql / strawberry-django

Strawberry GraphQL Django extension
https://strawberry.rocks/docs/django
MIT License
421 stars 123 forks source link

feat: Bump strawberry to 0.236.0 and refactor changed imports #591

Closed bellini666 closed 4 months ago

bellini666 commented 4 months ago

Changes required for https://github.com/strawberry-graphql/strawberry/releases/tag/0.236.0

Fix #590

Summary by Sourcery

This pull request updates the import paths in various files to be compatible with the changes introduced in Strawberry 0.236.0. This ensures that the project remains functional and up-to-date with the latest version of the Strawberry library.

sourcery-ai[bot] commented 4 months ago

Reviewer's Guide by Sourcery

This pull request updates the import paths across multiple files to align with the changes introduced in strawberry 0.236.0. The changes are primarily focused on refactoring the import statements to use the new module structure provided by the updated strawberry library.

File-Level Changes

Files Changes
strawberry_django/mutations/fields.py
strawberry_django/fields/field.py
strawberry_django/arguments.py
strawberry_django/fields/base.py
strawberry_django/fields/filter_order.py
strawberry_django/filters.py
strawberry_django/optimizer.py
strawberry_django/ordering.py
Refactored import paths to align with the updated module structure in strawberry 0.236.0.

Tips - Trigger a new Sourcery review by commenting `@sourcery-ai review` on the pull request. - Continue your discussion with Sourcery by replying directly to review comments. - You can change your review settings at any time by accessing your [dashboard](https://app.sourcery.ai): - Enable or disable the Sourcery-generated pull request summary or reviewer's guide; - Change the review language; - You can always [contact us](mailto:support@sourcery.ai) if you have any questions or feedback.
codecov-commenter commented 4 months ago

Codecov Report

Attention: Patch coverage is 97.77778% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.84%. Comparing base (8d997f8) to head (d80ec3b).

Files Patch % Lines
strawberry_django/mutations/resolvers.py 75.00% 1 Missing :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #591 +/- ## ========================================== + Coverage 88.82% 88.84% +0.01% ========================================== Files 41 41 Lines 3598 3604 +6 ========================================== + Hits 3196 3202 +6 Misses 402 402 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Elio-Nakhle commented 4 months ago

Thanks for the quick reaction to the strawberry version update.

One question though: Wouldn't it make sense from the semantic versioning perspective to pin the strawberry version while it stays a 0.x.x something? As with each release the strawberry people can theoretically introduce breaking changes with no prior announcement or restrictions. This way people who depend on this library can count on it not randomly breaking if they are not using lock-files.

You might say hey just use a lockfile. However, some people just use the django cookiecutter template and that doesn't have lockfiles (maybe it should I don't know) and just define the dependencies in requirements.txt and use those in the docker build setup.

Thanks for your efforts!

patrick91 commented 4 months ago

@Elio-Nakhle I think here I was at fault for not submitting a PR to this repo, the idea is to keep strawberry and strawberry django in sync (maybe we should have a ci test for that too), in fact the codemod I did was tested on this repo 😊

I think it's a good tradeoff to have this library not pin strawberry, as we usually don't do breaking changes like this. Pinning it would mean that Thiago would need to make a release every time we do a release too, which is not ideal 😊