This makes it easier to reuse pieces of the dagster-graphql schema, as well as smoothing the path for new contributors. Resolves https://github.com/dagster-io/dagster/issues/2270.
where there are collisions between the native/dagster type and the graphene type, we import the dagster type with the prefix Dagster
Previously we were relying on the implicit registry functionality / metaclass magic provided by Dauphin to load all of the types in the schema; this moves us to be explicit, which may or may not be better, but more importantly allows pieces of the schema to be imported by other projects without having to pull in the entire registry
There's nothing final or definitive about this reorganization, but I have tried to break up the very large files in dagster-graphql into more manageable chunks
retain Meta for unions
drop this boilerplate
wrap in lambda to avoid circular reference issue
move all interfaces to use tuples rther than lists
could also be __types__ or __all__
this moved off dauphin
python 3 super throughout
more format strings
moved input types together
no need for this to go through dauphin wrapper without the registry
lazy to avoid any import issues and allow subsets of the schema to be imported
here's an example of a fully-qualified string reference
trying to be explicit
I think this all makes sense to me.
We should probably merge this after the release today... (good luck with rebasing?) as we're probably relying more than usual on graphql test coverage to surface issues.
Are we losing any greppability here? It was kind of nice that all the
graphql type classes had a common prefix, we could consider adding a
GraphQL prefix or something by convention? Or is that what python modules
are for :)