I came across an issue with a generated schema that was missing a call to update_forward_refs()

It has an InputType that references another InputType that is later in the same file. The InputsPlugin looks like it tries to check for this by marking any InputType that references another InputType as self_referential.

My schema contains a nested non nullable InputType. This is is of type GraphQLNonNull and we don't check the value.type.of_type which shows that this is actually wrapping a GraphQLInputObjectType.

The reference is correctly written as a string. I'm not 100% sure where the code that determines which type hints should be strings lives.

When looking into this, I also noticed that there is a (presumably) related issue in the test_arkitekt_operations test.

This generates the following class at line 305

class Node(BaseModel):
    typename: Optional[Literal["Node"]] = Field(alias="__typename")
    name: str
    interface: str
    package: str
    description: str
    type: NodeType
    id: str
    args: Optional[List[Optional[ArgPort]]]
    kwargs: Optional[List[Optional[KwargPort]]]
    returns: Optional[List[Optional[ReturnPort]]]

But ArgPort is not defined until line 544

Problem

The code-generation produces to much output if you're only interested in generating input types and enums. The result isn't syntactically wrong, but not quite beautiful pydantic code.

Note: I overwrote the input-type base to generate code, that doesn't require turms installed in the final environment.

Setup

Project layout

| - graphql.config.yaml
|
| - graphql
|   | - schema.graphql
|
| - generated
|   | - types.py

graphql.config.yaml

projects:
  default:
    schema: /graphql/**/*.graphql
    documents: graphql/**.graphql
    extensions:
      turms:
        out_dir: /generated
        generated_name: types.py
        plugins:
          - type: turms.plugins.enums.EnumsPlugin
          - type: turms.plugins.inputs.InputsPlugin
            inputtype_bases:
              - "pydantic.BaseModel"
        processors:
          - type: turms.processor.black.BlackProcessor

schema.graphql

type Query {
    hello(orderBy: HelloWorldOrder! = ASC, filter: HelloWorldFilter,
        first: Int, last: Int, before: String, after: String): [World!]!
}

enum HelloWorldOrder {
    ASC
    DESC
}

input HelloWorldFilter {
    search: String!
}

type World {
    message: String!
}

types.py

from turms.types.object import GraphQLObject              # <-- not required
from turms.types.object import GraphQLObject              # <-- duplicate
from pydantic.fields import Field                         # <-- not required
from typing import Optional, List, Dict, Union, Literal   # Dict, Union and Literal not required
from enum import Enum
from pydantic import BaseModel


class HelloWorldOrder(str, Enum):
    None                                   # <-- Unused statement
    ASC = "ASC"
    DESC = "DESC"


class HelloWorldFilter(BaseModel):
    None                                   # <-- Unused statement
    ids: Optional[List[str]]

Expected Output

types.py

from typing import Optional, List
from enum import Enum
from pydantic import BaseModel


class HelloWorldOrder(str, Enum):
    ASC = "ASC"
    DESC = "DESC"


class HelloWorldFilter(BaseModel):
    ids: Optional[List[str]]

First of all, this seems like a nice project.

Would it be hard, to support loading the schema from a bunch of local .graphql files?

Currently, using a directory path as projects.default.schema in graphql.config.yaml isn't allowed.

It appears that "documents" is required in the config and cannot be null. I am relatively new to what documents are and I am having difficulty understanding their purpose. I have a full schema and an unaware of what the requirements is for documents.

Found that forward references would reorder themselves every time the file was generated. It's difficult to test as the ordering of a set is related to the random number seed.

I forced these to be sorted alphabetically which keeps the output file more consistent.

I also refactored some repeated code in registry.py but can remove that if you prefer.

In generate_query_doc(), when parsing the variable definitions, we check if the node is a ListTypeNode. The assumption is that the next node down will be a concrete type, but this can for example be a NonNullTypeNode which does not have a name.

for v in o.variable_definitions:
    if isinstance(v.type, NonNullTypeNode):
        if isinstance(v.type.type, ListTypeNode):
            description += f"    {v.variable.name.value} (List[{v.type.type.type.name.value}]): {v.type.type.type.name.value}\n"
        else:
            description += f"    {v.variable.name.value} ({v.type.type.name.value}): {v.type.type.name.value}\n"

The variable type that triggers this is [String!]!

I will have a look at creating a minimal example to reproduce this. I think it will probably require recursively parsing the variable definitions to resolve this.

When trying to generate functions for a schema that had mutations that returned a NonNull object I get the following error in ast.py.

def iter_fields(node):
    """
    Yield a tuple of ``(fieldname, value)`` for each field in ``node._fields``
    that is present on *node*.
    """
    for field in node._fields:

AttributeError: 'tuple' object has no attribute '_fields'

I have tweaked the beasts schema to cover this case and traced the root cause to a branch in recurse_outputtype_annotation() that returns a tuple. I don't think this should happen so I changed this line to return an ast.Name instead.

fixes #24

• Multiple inheritance could result in an invalid MRO of the generated pydantic types.

• If an interface was used as a forward reference, the wrong variable was used to call update_forward_refs().

may Fix #23

• Extended unraveling of wrapped type https://github.com/jhnnsrs/turms/compare/master...j-riebe:master#diff-ba9518bcc774b42fd3b54830810de2aa74832a6584657a094513b61c1d3517ceL243-R258

• Added test function that checks the generated module for runtime errors https://github.com/jhnnsrs/turms/compare/master...j-riebe:master#diff-9e08e8c7769db7b58089fd7659d75ca96df40bb7b5d50299d3a30abd54da9ad6R10-R23

• Added ability to create frozen classes

• Changed standard base class (pydantic Field), no more deps on turms itself

• Created hierarchy for overwritable baseclasses (object -> interface, object -> query, object-> fragment...)

• CLI updates

• FIX: typename for fragments

For the wishlist, I'd be very excited if turms could output snake_case code.

I know, you could use a BaseModel with an alias_generator to do the job of converting the GraphQL-camelCase to pythons snake_case. Unfortunately most python IDEs won't support code-completition based on this alias-generator.

Additionally, I noticed that class names can be generated in None-PascalCase if the corresponding GraphQL-Type is formatted accordingly.

type lowerCaseFirstType --> class lowerCaseFirstType

The pythonic way, would be to capitalize the first letter, no matter what. I understand, that this might cause confusion due to discrepancies with the schema or existing projects.

But to generate

Generate beautifully typed Operations, Enums,... (from Readme)

this (optional) feature would be awesome.

I know, that this might be a lot of work for some syntactic sugar (but: no pain no gain).

Keywords like from can't be used as field names.

The pydantic-graphql-codegen package does it like this, (but not for all keywords):

GQL

type Foo {
  from: String!
}

PY

class Foo(BaseModel)
    from_: str = Field(alias="from")

Hello, thanks for code generation lib for GrtaphQL! It is the real problem in python.

I created the package for pydantic data-model generation from some GraphQL schema and for queries and mutations generation: https://github.com/denisart/graphql2python Docs: https://denisart.github.io/graphql2python/

Queries generation examples: https://github.com/denisart/graphql-query Data-model generation examples: https://denisart.github.io/graphql2python/model.html

I hope that graphql2python can be useful to you and the python GraphQL community.

I'm trying to make a Strawberry API out of Pydantic classes generated by turms using the experimental https://strawberry.rocks/docs/integrations/pydantic support.

But I'm getting:

TypeError: GetExternalRunsResult fields cannot be resolved. Unexpected type 'typing.Literal['ExternalRun']'

which I think is the same problem as: https://github.com/strawberry-graphql/strawberry/issues/2317

Any idea for a workaround?

I searched for python typings graphql schema on github and didn't find this project: https://github.com/search?q=python+typings+graphql+schema&type=repositories

Not sure the graphql-codegen reference is useful in the description for users who have never used it.

There is no link to the github repo on https://pypi.org/project/turms/ .

The only reason I found this project is from the "shameless plug" at https://github.com/qw-in/graphql-codegen-pydantic/issues/10 :)

@jhnnsrs why do we even keep track of Forward Reference vs. direct call if we can just add

from __future__ import annotations

to the top of the file?

We would still need to call update_forward_refs() but the registration process would be just adding the type to a set "blindly". The annotation could be always generated ast ast.Name().

Example:

from pydantic import BaseModel

class Foo(BaseModel):
    bar: "Bar"

class Bar(BaseModel):
    test: str

Foo.update_forward_refs()

vs.

from __future__ import annotations
from pydantic import BaseModel

class Foo(BaseModel):
    bar: Bar

class Bar(BaseModel):
    test: str

Foo.update_forward_refs()

@jhnnsrs I think its time, that you take a look at this.

The PR contains the refactoring of EnumsPlugin, InputsPlugin and ObjectsPlugin. I mainly focused on breaking down the large functions into smaller methods of each Plugin. Some code duplication is eliminated, the remaining similarities should be pretty obvious by now (as a preparation for the next refactoring iteration). There is a new module ast_generators that contains all concrete AST-Generation logic that was (duplicated a lot) in every plugin before.

I have the feeling, that there also should be a stricter separation between the concerns:

• Schema Parsing (Main job of the Plugin)
• Registration (Which Objects/Enums/Inputs to include)
• AST-Generation (Translate GraphQL Type to pydantic Model + Plugin-specific types like Operations/Funcs)
• Custom Styling (influence ast-generation, not during class registration)

Currently, each plugin does almost everything. Only the styling is somehow part of the ClassRegistry, were it shouldn't belong IMHO.

Also, have a look at this test tests/plugins/test_objects.py::make_test_cases_union_field_value

Currenty, it's pretty hard to guess how the internal structure works. This is mainly due to the "superfunction" that generates each plugin code and the missing abstractions inside (which lead to a lot of duplication).

• [x] ClassRegistry #29
• [x] EnumsPlugin
• [ ] FragementsPlugin
• [ ] FuncsPlugin
• [x] InputsPlugin
• [x] ObjectsPlugin
• [ ] OperationsPlugin