Consider package name change

[danpalmer]

This may be controversial, but I'd like to propose changing the name of this package from graphql to something like graphql_next.

I'm working on a project that both exposes a GraphQL API, and does complex GraphQL introspection. Exposing an API is most easily done with Graphene, particularly given the packages like graphene-django, but it depend on graphql-core which as we know is fairly limited. I think it's reasonable to allow for the packages to be installed alongside each other.

Why

• Graphene operating at a higher level of abstraction, and with a developed package ecosystem means there is a need to have both this and graphql-core installed alongside each other.
• This package is not API compatible with graphql-core.
• PEP 423 suggests that top-level namespacing is about ownership. In this case "ownership" is arguably with https://github.com/graphql-python/ – this would suggest that installing under graphql_python.next, or graphql.next may be a good approach.
• PEP 423 suggests the following (emphasis mine), with a benefit being that packages do not collide. "Distribute only one package (or only one module) per project, and use package (or module) name as project name."
• graphql-core is no longer being actively developed. While this may change in the future, it means the maintainers are unlikely to change the name of that package.
• graphql-core came first, and it is recommended by PEP 423 that existing package names are not chosen by new packages.
• graphql-core-next mostly refers to itself by names along those lines, not by the name "graphql". This could be a chance to add consistency, and at the very least would be less confusing for newcomers than finding the package is in fact called "graphql".

How

PEP 423 suggests a reasonable series of steps, that don't look like they would required a huge amount of work.

https://www.python.org/dev/peps/pep-0423/#how-to-rename-a-project

Notes

I've referenced PEP 423 here a lot. It should be noted that this PEP has not been accepted, although it has received discussion on the Python-Dev mailing list, doesn't appear to have many people arguing against it (other than for broken links and typos), and has also been featured in conference talks. Above all though, the document reads to me as a summary of how the Python ecosystem already works for the most part, and a distillation of already accepted practices and the reasons for them, rather than a proposed change. For this reason I believe it's a good starting point for discussion.

I have also suggested several alternative names for the package here. I do not feel strongly about any of them. I think graphql_core_next, graphql_next, graphql.core, or graphql2, would all be acceptable names, and I am very happy to leave the decision between these or other new options entirely to the maintainers.

[Cito]

Thank you for this feedback and explaining the whys and hows regarding your request. It certainly makes sense and I understand you reasons. But I will also point out some reasons for sticking with the name.

First, the reason why the name "graphql" has been chosen is that both graphql-core and graphql-core-next are considered to be more or less 1:1 ports of GraphQL.js which also uses the package name "graphql". So it made sense that the Python package name is also just "graphql".

The name "graphql-core-next" for the project - it was originally called "GraphQL.py" in analogy to "GraphQL.js" - and moving the project into the graphql-python organisation was suggested by @syrusakbary, the creator of graphql-core. The idea was that graphql-core-next should actually replace graphql-core in the future. I.e. we currently think of graphql-core as just a version of the same package for older Python versions and graphql-core-next a newer version for newer Python versions and up to date with newer GraphQL.js versions. In that regard, you can consider graphql-core-next just the next major version of graphql-core.

The plan is also to have the APIs converge. In fact we have already made some changes in this regard, i.e. made graphql-core-next more backward compatible to graphql-core, and graphql-core more upward compatible. The idea is to have Graphene run with graphql-core-next in the future.

Unfortunately, we're currently moving a bit slowly as I have just changed jobs and Syrus also seems to be always very busy. But I plan to work on it again in the next month, bring graphql-core-next up to date with the latest GraphQL.js again, and talk with Syrus again about the way forward.

A name change might be an option, we will discuss it, and I will keep this issue open until we decide.

[danpalmer]

Hi @Cito, thanks for the thoughtful response.

In that regard, you can consider graphql-core-next just the next major version of graphql-core.

This seems to be the crux of most of your points. I am very much in favour of graphql-core-next replacing graphql-core in the long run, and for that I can see why having the same name would be handy. My concern is that hasn't happened yet, and appears unlikely to happen in the future.

For the moment the two projects are incompatible, and development on graphql-core, graphene and all related graphene projects has stopped. The discussions going on around the long term maintenance of those projects suggests that Syrus won't be returning to them, leaving their maintenance and roadmaps looking fuzzy.

This project is one part of the ecosystem that still seems to be making progress, and I would very much like to see it thrive. To achieve this, I think it needs to evolve to co-exist with Graphene et. al, assuming no further changes.

A name change would help support a new crop of tooling, as well as aiding the creation of community forks of the Graphene libraries, or alternatives to them.

[Cito]

Right, but I trust that even when Syrus stops working on the graphql-python projects, he is certainly willing to help hand over the organization and its project(s) to other community members as maintainers, so that we can proceed with the original plan. As far as I see (I haven't followed it so closely as I'm overloaded with work myself), he's already trying to find such people. That would be better than creating new forks and names if it can be avoided.

[messa]

Hi, I would like to help with development and/or organization of graphql-python projects.

[Cito]

@messa - thanks for your offer. Just found graphql-python/graphene/issues/884 where the future maintenance of graphql-python is discussed. I think that's the right place where we should continue this discussion. There is also graphql-python/graphene/issues/833 regarding the future of graphql-core-next.

According to the issue above, there will be a meeting in March. We should all probably wait for that meeting and try to attend if time permits.

[eMerzh]

@Cito , since the meeting is now over, i am really glad that you are able to find some times for this lib .... many thanks again!!

it seems if i'm correct, that graphql-core will still live for a bit at least ... does it change / ... your opinion about this one? being able to install -core then -core-next easily can really be helpfull for me :)

[Cito]

The suggested path forward on the meeting to which everyone seemed to agree was that graphql-core will be modernized so that it will be compatible with Python 3 and graphql-core-next. This work is going on in the "modern" branch of graphql-core, and as far as I understand, it is already largely completed by Syrus. Graphene and other libs from the Graphene ecosysteme will be made compatible with the modern branch. Several people volunteered to work on this. After that, graphql-core (modern) can be exchanged with graphql-core-next.

[Cito]

The current status/plan is that graphql-core-next will probably simply become graphql-core 3. Graphene 2 will be compatible with graphql-core 2, the upcoming Graphene 3 will be compatible with graphql-core 3 then. So the distribution name will be the same, and the package names should also be the same.

See also https://github.com/graphql-python/graphql-core/issues/241 for discussion of the versioning policy.