☂️ Graphene v3

[jkimbo]

This issue is to track v3 of Graphene which will contain some breaking changes.

Breaking changes

• Upgrade to graphql-core to v3 which brings feature parity with GraphQL.js v14.6.0
• Drop support for Python v2
• Schema type changes
• "Backends" have been removed
• Switch arguments from type to type_ since type is a builtin: "type" is a builtin in python; switch some arguments called "type" to be "type_" #738
• Upgrade to graphql-core v.3.1 which corresponds to GraphQL.js v15 (will be released soon).
• Change enum behaviour: Improve enum compatibility #1153
• Remove to_const function

TODO

• Write up some proper release notes: https://github.com/graphql-python/graphene/wiki/v3-release-notes
• Merge The default_value of InputField should be INVALID #1111
• Switch arguments from type to type_ since type is a builtin: "type" is a builtin in python; switch some arguments called "type" to be "type_" #738
• Remove to_const function: Remove to_const function #1212
• Change enum behaviour: Improve enum compatibility #1153
• Set minimum graphql-core version to v3.1 Set min version of graphql-core to v3.1.1 #1215
• Upgrade graphene-sqlalchemy to v3 WIP
• Upgrade graphene-mongo to v3 WIP

[jkimbo]

@dashmug graphene doesn't specify with version of graphiql you use. All you have to do is host GraphiQL yourself and point it at the grapqhl endpoint and it will work.

[AlecRosenbaum]

What is the release schedule for v3?

It looks like graphene is currently in beta 2, but what other revisions will there be before a non-beta release? How stable is the current beta? For new projects which version should be used?

[radekwlsk]

What is the release schedule for v3?

It looks like graphene is currently in beta 2, but what other revisions will there be before a non-beta release? How stable is the current beta? For new projects which version should be used?

@AlecRosenbaum AFAIK all that is left to do are proper release notes. I was supposed to help with that but unfortunately I couldn't find time for that this week.

If you would like to help feel free to start working on draft of said notes.

I hope to spend some time on that this weekend, but no promises.

[DoctorJohn]

If I interpret the initial comment correctly, the following tasks are left to do (correct me if I'm wrong):

• Merge "type" is a builtin in python; switch some arguments called "type" to be "type_" #738
• Merge Rename resolve_type method #775
• Finish Improve enum compatibility #1153 (?)
• Upgrade to graphql-core v.3.1
• Write up release notes

The master branch being version 3, I guess it's time to merge or properly close #738 and #755. @jkimbo you created on of these PRs and reviewed the other one. Would you mind taking a look at these?

For the graphql-core upgrade, we may need to take a look at their changelog(s) and at graphenes tests.

Last but not least the release notes. I'd imagine them similar to the previous ones (v1, v2). They should cover all changes listed in the initial issue. One might need to look trough v3 commits to properly cover schema type changes.

[jkimbo]

@DoctorJohn I came to the conclusion that #775 is not actually needed (reasons here: #775 (comment)). Also #738 needs to be brought up to date with master because it's quite old. @radekwlsk @DoctorJohn if either of you could help with that that would be great.

Other than that that list looks right, I've updated the description to include them.

[jkimbo]

Also I'm going to try and find some time this week to finish #1153 but no promises unfortunately.

[jkimbo]

#1153 is ready for review now. If anyone has the time to take a look it would be most appreciated.

[jkimbo]

Ok #1153 has been merged and I've written up some release notes: https://github.com/graphql-python/graphene/wiki/v3-release-notes

If anyone is able to try out the latest beta in their projects that would be very helpful. Otherwise I think we should aim to release v3 in the next couple of weeks.

[AlecRosenbaum]

We've been running graphene==3.0b2 in production since mid to late June without any major issues. Only a small number of our internal APIs have been migrated to use graphql (from REST), but it still does see regular usage.

We previously were using the graphql-core library directly on v2. We updated from v2 to v3, then migrated all of that to graphene v3 without any major issues.

@jkimbo Thank you for all the work you've done on this project!

[radekwlsk]

I've prepared migration of our project to graphene/graphene-django/graphql-core v3 from v2. No bigger issues there, mainly with new fixed Enums and more low-level stuff that simple projects shouldn't touch (for example our own pagination with filtering not using Relay, custom scalar types and custom Mutation base).

We plan to start testing it on dev or staging environment soon, mainly to check the performance bump from #1157. Once we do that I will let you know @jkimbo if there were any issues or bugs found.

[hyusetiawan]

is V3 backward compatible with third-party or even first-party plugins such as:
https://github.com/graphql-python/graphql-ws
https://github.com/tfoxy/graphene-django-optimizer
https://github.com/eamigo86/graphene-django-extras
?

Also, any guide on migration?

[jkimbo]

Thanks @AlecRosenbaum @radekwlsk , good to know that you haven't encountered any issues. I've been using the beta release for the past couple of months and I haven't found any problems either.

Regarding a release date for v3: @syrusakbary has decided that v3 needs to include a new annotation based object type api. I don't have an ETA on when that will be implemented but I have been assured that it won't take long.

---

@hyusetiawan

is V3 backward compatible with third-party or even first-party plugins such as:
graphql-python/graphql-ws
tfoxy/graphene-django-optimizer
eamigo86/graphene-django-extras
?

I haven't checked that but the graphene-django-optimizer and graphene-django-extras library depend on graphene-django and the v3 release of that is tracked here: graphql-python/graphene-django#705

Thanks for raising it though, I'll try and make sure that those libraries have been checked against v3 of graphene-django before releasing it.

[hyusetiawan]

@jkimbo I can attest that django-graphql-jwt has v3 support already merged, tested it and it has been running smoothly: flavors/django-graphql-jwt#213

[fabienheureux]

is V3 backward compatible with third-party or even first-party plugins such as:
https://github.com/graphql-python/graphql-ws
https://github.com/tfoxy/graphene-django-optimizer
https://github.com/eamigo86/graphene-django-extras
?

Also, any guide on migration?

I started a PR for graphene-django-extras, if you want to test it eamigo86/graphene-django-extras#148

I had no issues with django-graphql-jwt so far.
I don't use graphene-django-optimizer, so I can't tell 🤔

[syrusakbary]

A quick update on this. We decided to not block the release of Graphene v3 based on typing, since it might take longer than we expected.

However, we are pending to updated the GraphQL-Python Graphene dependencies (such as graphene-mongo, graphene-sqlalchemy and so) to support Graphene 3.0 and GraphQL-core 3.0. So, until we don't update those dependencies to support Graphene v3, we can't publish the new version.

Note: the conversations are happening in Graphene Slack channel, in #graphene3-releaseplan channel.

[radekwlsk]

@jkimbo
In release notes it should state that not

Misc. Changes
Relay's ConnectionField get_resolver function renamed to wrap_resolve

but rather

Misc. Changes
Field's get_resolver function was replaced by wrap_resolve

Also

warn_deprecation(
    "The get_resolver method is being deprecated, please rename it to wrap_resolve."
)

should rather be in in __init__ than wrap_resolve, I've spend almost an hour fixing my PagePaginationDjangoFilterField(DjangoListFilterField) that overwrites get_resolve and

/home/django/venv/lib/python3.8/site-packages/graphql/type/definition.py:745: in fields
    raise TypeError(f"{self.name} fields cannot be resolved. {error}")
E   TypeError: Query fields cannot be resolved. type object 'PaginatedMyType' has no attribute 'of_type'

error was not really helpful.

As a side note:
Would you be interested in PR with my DjangoListFilterField and PagePaginationDjangoFilterField that introduce django-filters and pagination without use of Relay?

[corydolphin]

A quick update on this. We decided to not block the release of Graphene v3 based on typing, since it might take longer than we expected.

However, we are pending to updated the GraphQL-Python Graphene dependencies (such as, graphene-mongo graphene-sqlalchemy and so) to support Graphene 3.0 and GraphQL-core 3.0. So, until we don't update those dependencies to support Graphene v3, we can't publish the new version.

Note: the conversations are happening in Graphene Slack channel, in #graphene3-releaseplan channel.

Would it be possible to update those dependent packages after the release? Those libraries look to have an order of magnitude less usage. I’m sure others are anxious to update to graphene 3 and are waiting on a final release. It may also help to drive momentum and contributors to help with those extension packages’ upgrade process.

[corydolphin]

It also looks to have become chicken and egg: graphql-python/graphene-sqlalchemy#248

[jnak]

@syrusakbary What's the rationale for blocking the release of graphene on the update of dependent projects such as graphene-sqlalchemy?

I'm personally in favor of releasing graphene as soon as it's stable and let the various projects add support at their own pace. This is a big migration for dependent packages as it implies completely dropping support for Python 2, migrating away from promise and dataloader and assuming everything now runs in an event loop. And it's probably a good moment for those packages to introduce API changes they have been pushing back for a while. I'd rather not rush maintainers to release a new version if we don't technically need to. Those projects should have all pinpointed graphene v2 in their requirements file there is no risk they will break when the next version of graphene v3.

[mvanlonden]

We're almost there! Two more graphene libraries need to support v3, graphene-sqlalchemy – WIP and graphene-mongo – WIP. If we can get tests passing on these last two PRs, we can release graphene v3.

@DoctorJohn and @zsiciarz can you bring us over the finish line? Any blockers on your current WIP PRs? @jetzhou also offered to help with the sqlalchemy upgrade. @jetzhou can you work with @zsiciarz to bring this PR home?

[richin13]

Actually looks like graphene-mongo was migrated to v3 (https://github.com/graphql-python/graphene-mongo/blob/98f2929956d199ab4c11f8db5f9bdbf361a70bbc/setup.py#L25) and has all its tests passing. (Unless I'm missing something?? 😅 )

It's only graphene-sqlalchemy at this point, for which PR graphql-python/graphene-sqlalchemy#317 exists (fixes all broken tests). We just need to have graphql-python/graphene-sqlalchemy#316 merged so that we can run the tests against the PR (Travis is broken)

[keithhackbarth]

Is there a reason we don't just don't let the downstream repositories manage their own dependencies and upgrade at their leisure? Isn't that why each repo has its own requirements file - so they can pin to v2 if they aren't ready to upgrade? I can't think of any other codebase in the python ecosystem that requires all of its downstream repositories to upgrade before the official version of the upstream one gets released. Does anyone have an example of this? It feels very "cart before the horse", no?

[pappasam]

@keithhackbarth let's answer this question once v3 is actually released. @richin13, @DoctorJohn, @zsiciarz, and others have jumped through flaming hoops, so let's not let a potential flame war slow things down!

[AntonOfTheWoods]

@pappasam , "slow things down". Really? It is probably mathematically impossible to go any slower than this issue has been managed. It will soon be multiple YEARS since this repo has been waiting for the downstream repos to confirm compatibility.

[McPo]

Is there a reason we don't just don't let the downstream repositories manage their own dependencies and upgrade at their leisure? Isn't that why each repo has its own requirements file - so they can pin to v2 if they aren't ready to upgrade? I can't think of any other codebase in the python ecosystem that requires all of its downstream repositories to upgrade before the official version of the upstream one gets released. Does anyone have an example of this? It feels very "cart before the horse", no?

I 1000% agree. Theres also little motivation for the other projects to upgrade if they are still technically on the stable build.

As they get left behind, they may be more likely to get up to speed. And if they don't then they don't have the userbase to warrant the effort.

Contributors are also more likely to help when they see that an actual release has occured. There's simply no way Id dedicate any of my time to this project simply because it's in release hell. Sure it's inching ever so slowly, but Im more likely to contribute to a OSS (and thus get the child dependencies up to speed quicker), if I can see quick returns on my effort. Not taking years to release.

BTW I'm not even that motivated for a new release of this project, as I've since moved on. So if this is coming across as abrupt then I do apologise, it's definitely not meant that way. However I do think who ever decided such a policy needs to seriously rethink it. I feel it stifles any incentive in getting involved in the project, and simply grinds it to a halt. Move on and let the dependencies catch up.

[mark7-bell]

We need to assess whether v3 addresses performance problems we are seeing, or we need to find another technology soon.

[JBrVJxsc]

We need to assess whether v3 addresses performance problems we are seeing, or we need to find another technology soon.

v3 uses native asyncio instead of the Promise libraries that are being used by v2.
v3 should be a lot faster than v2.

however, we are waiting for v3 for soooo long.

[mvanlonden]

With the release of v3 graphene-sqlalchemy, all dependent libraries now support v3. This unblocks the release of v3!

[lovetoburnswhen]

With the release of v3 graphene-sqlalchemy, all dependent libraries now support v3. This unblocks the release of v3!

at long last

[AntonOfTheWoods]

The cows have come home!!!!!

[colelin26]

With the release of v3 graphene-sqlalchemy, all dependent libraries now support v3. This unblocks the release of v3!

Thanks for the fast code review and release! Glad to see that my code was able to help :) I think it really shows that a lot of us from the community are willing to help and how important Graphene is to us.

[tstordyallison]

What are next steps for cutting a release? Looks like all the downstream libraries are ready.

[cglacet]

@tstordyallison according to the checklist the last point is supposed to be checked by this merge?

[tstordyallison]

Yep! I think we are good to go. We just need someone to cut the release AFAICT.

[Birdi7]

@jkimbo @ekampf hello! do you have any thoughts on releasing v3.0?

[felixmeziere]

🥱

[jmg-duarte]

WRT the last TODO, it seems as though it has been merged in graphql-python/graphene-mongo#172

[mvanlonden]

Cut v3.0.0 today

https://github.com/graphql-python/graphene/releases/tag/v3.0.0

[felixmeziere]

@syrusakbary any progress with this #1127 (comment) ? ... :/

[kubami]

What is the outstanding tasks to releasing the v3? All the TODO items have been checked off. I have been using the 3.0.0b7 for a year now.

[flbraun]

@kubami Graphene v3 has already been released on Nov 13 2021 (see PyPI). Not sure what you're after?

[aryadovoy]

What about UPGRADE-v3.0.md?

[jkimbo]

@aryadovoy the release notes for v3 should cover all the changes you need to make: https://github.com/graphql-python/graphene/wiki/v3-release-notes