print_schema doesn't support user-defined directives

https://github.com/graphql-python/graphql-core/blob/main/src/graphql/utilities/print_schema.py#L208 is made in a way that just supports @deprecated, however fields may get other directives, such as validation, permissions or display hints.

This is also the case with print_input_value that only handles deprecated directive.

[Cito]

I think I explained it in #90. The declared goal and scope of this project is to be a 1:1 port of GraphQL.js and its API to Python, even down to the level of implementation details and tests, and to keep it in sync with the latest development in GraphQL.js, where they are continually moving forward: fixing bugs, adding functionality and keeping in sync with changes and additions to the GraphQL spec.

I am so adamantly sticking to this scope and trying to not extend it, because it’s the only modus operandi that allows me to maintain this project in my limited spare time (I’m not paid for this work) and to keep it up to date and in sync with the functionality of GraphQL.js in the long run. The more GraphQL-core deviates from GraphQL.js, the more difficult it will become to stay up to date. I have already seen this with GraphQL-core 2, which added functionality, but at one point in time stopped keeping in sync with GraphQL.js (I think it was at version 0.6.0) because they already deviated too much, after which it fell behind and quickly became outdated. That’s why I created GraphQL-core 3 with the declared goal of just being a port of GraphQL.js, not more and not less. That’s also why a “bug” in the context of this project must be measured only against the goal of this project being a functional port of GraphQL.js or not.

If some functionality of GraphQL.js is missing or considered a bug, the way to proceed is to submit an issue on the GraphQL.js issue tracker and convince the GraphQL.js folks to add the functionality or to fix the bug. They have more competent people and resources, and more expertise to decide whether and how some functionality or API should be changed, and they are very approachable and usually eager and quick to fix bugs. Then, after it is implemented in GraphQL.js, it will be also ported to GraphQL-core, and everyone benefits, both the users of GraphQL-core and the users of GraphQL.js. Another way to add functionality would be to create a supplementary library or tool that uses GraphQL-core. The reason this library is called “-core” is because it provides just the core functionality that other libs (like Graphene) can build upon. A third option would be to fork or create a new library that has a “higher goal” than GraphQL-core, and would include more functionality, and maybe offer a more Pythonic API or better performance due to an implementation that is more optimized for how Python works. I am totally not against this. But inside this project, I want to stick to the given scope.

I’m sorry if this is not the response you had hoped for, but I hope you understand my reasoning.

[barbieri]

And I saw couple of tickets, one still open, that would address that: https://github.com/graphql/graphql-js/issues/2020

If that ever gets into the GraphQL.JS, I’ll ping here