Roadmap getting us from legacy to modern version

[KingDarBoja]

Python 2 has reached EOL and no further development will be done as stated on the official Python release schedule page for 2.7

Being the last of the 2.x series, 2.7 will receive bugfix support until 2020. Support officially stops January 1 2020, but the final release will occur after that date.

Planned future release dates:

2.7.18 code freeze January, 2020
2.7.18 release candidate early April, 2020
2.7.18 mid-April, 2020

Also, Python 3.5 support will stop at 2020-09-13 as seen at status-of-python-branches, so would be great to drop support for Python 3.5 in order to push forward and use 3.6+ features on the code (like f-strings).

[Cito]

This should happen together with the switch from GraphQL-Core version 2 to version 3.

@ekampf has been already working on that in the gql-next repository. That work should be merged back here and released as new major version of gql. But as long as we support the GraphQL-Core legacy version 2 which explicitly supports Python 2, we should also support the legacy Python 2.

My suggestion is to fast forward the version number of the current gql to version 2, and then release the version based on GraphQL-Core 3 as version 3. This versioning scheme has also been used with other GraphQL-Core based libraries such as Graphene.

[KingDarBoja]

Sounds good, the only issue (which I have no idea) is the merge step, as I see there is not too many shared stuff between each version, perhaps the upcoming gql version (or v3) is made from scratch, right?

And regarding the fast forward to v2 following the semantic versioning process, is there any schedule date?

[Cito]

Regarding the merge step, give me some time to look into this and decide how to best merge the two since now gql has moved forward. With "from scratch" you still mean based on the code and API of v2, or do you want to create a completely new API?

Regarding the timing for v2, we should first triage the open issues and PRs and check if there are bugs that should be fixed or features that should be added to v2, or be postponed or rejected for good reasons. It would be great if you could help with that.

[KingDarBoja]

Regarding the "from sratch", I was actually asking about how it was done since it doesn't seem to be the same repository organization (files, directories, functions) on the quick look between gql-next and gql.

I am open to keep contributing to the already existing open issues, which some of them have been addressed on some PRs, but I do feel like those can be done in a better way.

Once again, not the most skilled on the GraphQL spec but willing to improve and keep contributing 👍

[Cito]

Just talked with @ekampf and had a look at his gql-next repository. Actually, he created a pretty different mechanism for loading GraphQL documents, that includes auto-generation of Python files, it's not just a simple port of gql to core-next as I thought earlier. We need to decide whether we should port some of that work back here or whether we should keep the mechanism as it is.

I also wonder whether it would make sense to support importing GraphQL documents directly from Python by hacking the import machinery.

[Cito]

I also think before releasing a new major/final version, the obscure dsl language should be documented. It is currently unclear to me where it is coming from, whether it mimics an existing thing or was an invention of Syrus. Does anybody know?

[KingDarBoja]

I also think before releasing a new major/final version, the obscure dsl language should be documented. It is currently unclear to me where it is coming from, whether it mimics an existing thing or was an invention of Syrus. Does anybody know?

Not an invention but more like an alternative to simple JSON queries.
You can check these blog posts to see where it came from (of course, more can be found on Google):

• Writing a GraphQL DSL in Kotlin
• GraphQL SDL

In fact, it should be spelled like "SDL" instead of "DSL" 🤔

[Cito]

SDL has a well defined meaning as the "schema definition language" of GraphQL. But DSL means "domain specific language" and could be anything. I think it's a bit misleading, because "domain" is probably meant to be "GraphQL" in this case. But it usually means application domain, while GraphQL is general purpose and the "DSL" here is also intended to be general purpose. just an alternative way to express GraphQL documents in Python instead of JSON. Similar to the "SQL Expression language" in SQLAlchemy which allows writing SQL queries in Python.

[KingDarBoja]

Makes sense now, as the DSL search yield few results compared to SDL.

Regarding the merge with gql-next repo, I saw the readme weeks ago and had the same feeling but didn't expected to be a entire different thing. The best action could be moving (cherry picking maybe?) the gql-next stuff into this repo but first update all gql to fit Python 3.6+.

[leszekhanusz]

Hi,
Do you have any comments about the approach I used in the pull request #70 ?
I started to add async methods to the existing Client class but it appears that most of my code had no place there so I put it all in an AsyncClient class (and same for AsyncTransport)
In addition fetch_schema_from_transport=True cannot work for async transport because we cannot use await in __init__ so I added a fetch_schema method