feat: Bump strawberry to 0.236.0 and refactor changed imports

[bellini666]

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.

• Enhancements:
  • Updated import paths to align with the new structure introduced in Strawberry 0.236.0.

[sourcery-ai]

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:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[sourcery-ai]

Hey @bellini666 - I've reviewed your changes and they look great!

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[codecov-commenter]

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 ⚠️

Additional details and impacted files

@@            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              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Elio-Nakhle]

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]

@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 😊