Closed bellini666 closed 4 months ago
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.
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. |
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: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
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!
@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 😊
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.