Add support for graphql-core 3.2.0

[ddelange]

Add minor pin on graphql-core as their minors are synchronized with upstream majors (docs)
Only run push trigger on master branch
Remove poetry.lock ref https://stackoverflow.com/a/61076546/5511061

Fixes #26

$ pipgrip --tree starlette-graphene3@git+https://github.com/ddelange/starlette-graphene3.git@patch-1
starlette-graphene3@ git+https://github.com/ddelange/starlette-graphene3.git@patch-1 (git+https://github.com/ddelange/starlette-graphene3.git@patch-1)
├── graphene>=3.0b6 (3.1)
│   ├── aniso8601<10,>=8 (9.0.1)
│   ├── graphql-core<3.3,>=3.1 (3.2.1)
│   └── graphql-relay<3.3,>=3.1 (3.2.0)
│       └── graphql-core<3.3,>=3.2 (3.2.1)
├── graphql-core<3.3,>=3.1 (3.2.1)
└── starlette>=0.14.1 (0.20.1)
    ├── anyio<5,>=3.4.0 (3.6.1)
    │   ├── idna>=2.8 (3.3)
    │   └── sniffio>=1.1 (1.2.0)
    └── typing-extensions>=3.10.0 (4.2.0)

[ddelange]

@erikwrede if there's more you spotted, plz let me know :) CI is passing on my fork

[flipbit03]

LGTM!

[erikwrede]

I think the changes are possible without dropping support for graphene 3.0. GQLFormattedError should already exist in the former GQL-Core release - will check tomorrow.

[ddelange]

It looks like GQLFormattedError was introduced in graphgl-core 3.2.0 in the same commit graphql-python/graphql-core@09ff14f (from diff graphql-python/graphql-core@v3.1.7...v3.2.0)

Since graphene 3.1 is the first release to (properly) support graphgl-core 3.2.0, I think this lower pin makes sense. Previous versions of this lib can still be used with graphql-core<3.2, risking dephell with the earlier versions of graphene/gql/graphql-core/graphql-relay.

[ddelange]

from a closer look: graphene 3.1 still allows graphql-core 3.1, whereas this PR drops support. so either this PR should introduce compat import statements, or this PR should drop support:

Suggested change

	graphene = "~=3.1"
	graphene = "~=3.1"
	graphql-core = "~=3.2"

what do you think?

[erikwrede]

Your suggestion seems to be necessary to prevent compatibility issues. Whether or not to introduce compatibility import statements is a question of scope. This is a quick fix, compatibility imports would increase complexity.
The cleaner way to go would be by supporting all core versions that graphene supports, aligning with the main library.

[ddelange]

towards preventing future compatibility issues: ddelange#2

I think it's one step forward, plz let me know what you think :)

[ddelange]

@ciscorn if you get the chance, please squash this PR as it turned out to be more than one commit 😅

[ciscorn]

thank you!