☂️Graphene-Django v3

[jkimbo]

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

WIP branch: v3 (compare)

Breaking changes

• Upgrade to Graphene v3 (which also upgrades graphql-core to v3) (PR work in progress: WIP: Graphql next #905)
• Convert MultipleChoiceField to List of type String (Convert MultipleChoiceField to List of type String #611)
• Start raising DeprecationWarnings for using only_fields and exclude_fields (see Alias only_fields as fields and exclude_fields as exclude #691) (PR Start raising DeprecationWarnings for using only_fields and exclude_fields (v3) #980)
• Start warning if neither fields or exclude are defined on DjangoObjectTypes Start warning if fields or exclude are not defined on DjangoObjectType #710 (PR Warn if fields or exclude are not defined on DjangoObjectType #981)
• Default CAMELCASE_ERRORS setting to True (PR Default CAMELCASE_ERRORS to True #789)
• Rename DJANGO_CHOICE_FIELD_ENUM_V3_NAMING to DJANGO_CHOICE_FIELD_ENUM_V2_NAMING and default it to False (reference Add options to override how Django Choice fields are converted to Enums #860) (PR Make v3 django choice field enum naming default (in v3) #982)
• Convert decimal fields correctly: Convert DecimalField to String rather than Float #91

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ktosiek]

Hey stale bot, this issue is not dead yet, it's just getting started!

[ktosiek]

Has anyone started working on this? I'm currently trying to just make tests pass under graphene 3.

[swist]

Is there an up to date todolist on this? I have a couple of days this week so can pick it up and finish off your branch

[ktosiek]

I think it's complete enough to try building on top of it (porting an actual application, or checking if graphene-django-optimizer works).
It would also be nice to drop the dependency on promise.

[patrick91]

@ktosiek we could try with https://github.com/graphql-python/swapi-graphene

I wanted to test graphene 3 at work, but we are still on v1 :D

[swist]

I've just tried it on my current project. Seems to work fine minus some of our custom graphene types that allow us to use django_more/django_enum

[BfutureP]

graphene-django doesn;t support graphql 3, says from graphql import get_default_backend not found

[garimagupta715]

is asgi server supported in graphene. how can we implement subscription with graphene

[ulgens]

Any progress on this?

[rhizoome]

@ulgens Last month I started to run graphen-django v3 against our test-suite (https://github.com/projectcaluma/caluma), but I got distracted by other projects. I was able to reduce errors from 500 of 600 to about 150 of 600. I assume there are still bugs in the graphql*/graphene* projects, some are in caluma itself of course. I hope I can resume the work in February.

[ulgens]

@ganwell Thanks for answering to both of my comments 🙂 Is there any way to push your work, so we can continue on that?

[ulgens]

Or maybe, somehow, we can do some partial / incremental changes? I think it'd be more productive and beneficial for everyone.

[rhizoome]

@ulgens

I did two things:

1. Match the revisions of all projects to minimize the amount of inconsistencies and give me a base to work without confusing errors because of version mismatches, this was quite a task: https://github.com/ganwell/gwork

2. One pull request with an actual bug: The default_value of InputField should be INVALID graphene#1111

I want to continue working with the versions in gwork till I found all bugs I can with these versions and the I would iterate and update the versions.

[ulgens]

Hey everyone, i used existing PR and solved all left errors: #905

[ulgens]

Hey @jkimbo, for DJANGO_CHOICE_FIELD_ENUM_V3_NAMING settings, instead of defaulting it to True i think this setting should be removed and instead, we should intruduce a new one for V2_NAMING to revert changed behaviour.

[jkimbo]

@ulgens that sounds like a good idea!

[rhizoome]

Hey everyone, i used existing PR and solved all left errors: #905

@ulgens Thanks a lot. I currently have the problem that my work is based on #774 and yours is not. I don't know how to proceed at the moment.

caluma test-suite:

355 failed, 222 passed, 96 errors
281 failed, 296 passed, 96 errors
163 failed, 414 passed, 96 errors
161 failed, 500 passed, 12 errors
Switch: 342 failed, 319 passed, 12 errors

I am more or less back where I started. I guess I will continue on #774 and check for every bug if you have already fixed it.

[ulgens]

@ganwell There is small issue with commits in my branch, i can fix it tomorrow. There is no failing test in it, so i think we can continue from there.

[JSv4]

@bellini666, the way I found this thread was via your note in the graphene-django-plus repo (cool project btw). I do appreciate the heads-up and wish I had known about all of the above discussion sooner. That said, those kinds of deprecation warnings before a project is right and truly dead (there was a release just a few months ago) will only accelerate the process. Perhaps that's the point though?

[bellini666]

@bellini666, the way I found this thread was via your note in the graphene-django-plus repo (cool project btw). I do appreciate the heads-up and wish I had known about all of the above discussion sooner. That said, those kinds of deprecation warnings before a project is right and truly dead (there was a release just a few months ago) will only accelerate the process. Perhaps that's the point though?

Hey @JSv4, not really the point (wasn't expecting it to attract attention to this thread =P), but maybe that's actually good because it contribute to start focing an action to be taken, either to really acknowledge it as deprecated or for someone to step up.

I'm following this and the other thread at graphene repo and I sometimes see someone here and there commenting on wanting to help to keep it alive. I'm really hoping someone will :)

Also, glad to see you liked graphene-django-plus. I'm putting a lot of efforts on strawberry-django-plus now (clearly naming projects isn't my greatest skill :P) so, if you ever want to try strawberry, be sure to check it out!

[JSv4]

@bellini666, well, I'm glad it did attract attention as it seems the Graphene ecosystem is not as healthy as it would first appear from raw stats (going off of comments I'm seeing in the Slack and elsewhere). Tbh, I've never been a huge fan of Graphene's API, particularly the Django integration. It works, but I often do a lot of things manually with more boilerplate as I don't like the graphene-django magic. That said, Graphene's biggest advantage is the sheer number of libraries that are available for it (and the relatively tight Django integration, despite its flaws). Since you're moving to Strawberry, I wonder how you've found the options for 1) ORM integration, 2) auth (particularly JWT) and 3) permissioning. Do you have a recommended stack? I would love to try Strawberry, but I don't have time to rebuild a lot of the utility libraries I take for granted on Graphene (even if some have their issues).

[bellini666]

@JSv4 I did not find much alternatives since strawberry is indeed a young project. But having said that:

1. There's already an official django integration available which can be used for ORM integration. I would recommend my strawberry-django-plus lib, specially if you were already used to graphene-django-plus. It is based on the official integration, but I'm enhancing it a lot (e.g. It provides an extension that does sql optimization, much better than graphene-django-optimizer ever did). Take a look here for more information and some examples.

2. I'm planning on adding JWT to my extension there pretty soon (in the next couple of weeks)

3. Also something I solved in my extension, using schema directives. Take a look here for more information and some examples.

[Luferov]

Strawberry is too young project to “production ready” that wants to cover everything that is possible, there are fastapi, and flask, and whatever you want. I don't think this is a good solution. What about SqlAlchemy? Of course, there is enthusiasm because the project has just appeared. I really love Python and I also love graphql, they makes working with the frontend much easier.
It's just that the library is already ready to switch to graphene3, a lot of people use it, I can't understand why can't switch to graphene v3.
In addition, this library works well with Django-filter. There is an implementation of subscriptions: https://github.com/datadvance/DjangoChannelsGraphqlWs. We are currently developing convenient filtering on relay.

Pydantic and type annotation are a great idea for graphene_django v4.

[felixmeziere]

Guys from Graphene's Slack it seems the project might come back from the dead as it should

[cpontvieux-systra]

Well it was ONE month ago and nothing moved…

[felixmeziere]

Well it was ONE month ago and nothing moved…

We're slowly starting to get used to it...

[Luferov]

We decided to switch to nestjs, we will use subgraph there and migrate calmly from graphene. While graphql is not so developed in the Python community, to my great regret:(

[jedie]

We decided to kick graphene-django but stay with graphene for the moment.

[moritz89]

Looking at the todo list, it seems like all tasks are done for a v3 to be released. Is there anything blocking making a release?

[Luferov]

Looking at the todo list, it seems like all tasks are done for a v3 to be released. Is there anything blocking making a release?

The wish of the maintainers 😺

[tcleonard]

I agree! Will try to get that out (I'm not sure I have the required permissions)

[ulgens]

@tcleonard I do 🌹

[dkruk]

Any chance to see this alive?

[firaskafri]

We are now trying to revive activity to this great repo! Everyone willing to help please let's all start with a cleanup for all stale issues and PR's!

[ulgens]

@firaskafri It's good to see there is some active development going on, but I couldn't really catch what is going on. The repo was in near dead state for a long time, not because we have no one to merge PRs; but because we lost the community, and there is a better alternative now. If the current effort is to give one last maintenance release, I can give my full support but if the intention is really to "revive" the repo and the community, I think it will just postpone the EOL.

In any case, we are already late for putting a "this project is dead" warning on top of the readme. Even with the best effort to clean open PRs and issues, if there is no plan for long-term support, making people think graphene-django is a good option to start their new projects with will be just harmful IMO.

[firaskafri]

@ulgens I know of tens of people who rely on this and many who chose to do their own fork, there is a big community of people who lost hope in activity here. The intention is to make v3 see the light and make it stable enough for those they use it. If it organically manages to go on, then be it, otherwise it gets an honorable EOL.

[ulgens]

I know of tens of people who rely on this and many who chose to do their own fork, there is a big community of people who lost hope in activity here.

If this is true, what you define is a group of consumers that doesn't contribute to the project but expects results from it, which doesn't really satisfy the term "community" in the scope of free software. Of course, we shouldn't and we can't discourage anyone from contributing but ignoring the project was already dead for the last two years is not the best way of communication, IMO.

If it organically manages to go on, then be it

🙏🏻 🤞🏻

[firaskafri]

v3.0.0 is here 🎉