Fix: model list schema constraints error when using Pydantic V1

[juantoca]

What's being fixed

As a user of Pydantic V1, there are some models that use constraints on Pydantic List fields that fail on import:

ValueError: On field "annotations" the following field constraints are set but not enforced: max_length. 
For more details see https://docs.pydantic.dev/usage/schema/#unenforced-field-constraints

Reproduction steps

On the root of the project, with the venv populated and activated:

$ pip install "pydantic<2"

$ python
> import githubkit.versions.v2022_11_28.models.group_0932

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/juan/Documentos/OpenSource/githubkit/githubkit/versions/v2022_11_28/models/group_0932.py", line 21, in <module>
    class ReposOwnerRepoCheckRunsPostBodyPropOutput(GitHubModel):
  File "pydantic/main.py", line 197, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/fields.py", line 502, in pydantic.fields.ModelField.infer
  File "pydantic/schema.py", line 1021, in pydantic.schema.get_annotation_from_field_info
ValueError: On field "annotations" the following field constraints are set but not enforced: max_length. 
For more details see https://docs.pydantic.dev/usage/schema/#unenforced-field-constraints

Solution

To palliate this issue, a ternary operator might be injected on the Pydantic Field constructor to disable or enable the constraints depending on the library version:

from githubkit.compat import PYDANTIC_V2
annotations: Missing[
        List[ReposOwnerRepoCheckRunsPostBodyPropOutputPropAnnotationsItems]
    ] = Field(
-        max_length=50,
        default=UNSET,
        description='Adds information from your analysis to specific lines of code. Annotations are visible on GitHub in the **Checks** and **Files changed** tab of the pull request. The Checks API limits the number of annotations to a maximum of 50 per API request. To create more than 50 annotations, you have to make multiple requests to the [Update a check run](https://docs.github.com/rest/checks/runs#update-a-check-run) endpoint. Each time you update the check run, annotations are appended to the list of annotations that already exist for the check run. GitHub Actions are limited to 10 warning annotations and 10 error annotations per step. For details about how you can view annotations on GitHub, see "[About status checks](https://docs.github.com/articles/about-status-checks#checks)".',
    )

from githubkit.compat import PYDANTIC_V2
annotations: Missing[
        List[ReposOwnerRepoCheckRunsPostBodyPropOutputPropAnnotationsItems]
    ] = Field(
+        max_length=50 if PYDANTIC_V2 else None,
        default=UNSET,
        description='Adds information from your analysis to specific lines of code. Annotations are visible on GitHub in the **Checks** and **Files changed** tab of the pull request. The Checks API limits the number of annotations to a maximum of 50 per API request. To create more than 50 annotations, you have to make multiple requests to the [Update a check run](https://docs.github.com/rest/checks/runs#update-a-check-run) endpoint. Each time you update the check run, annotations are appended to the list of annotations that already exist for the check run. GitHub Actions are limited to 10 warning annotations and 10 error annotations per step. For details about how you can view annotations on GitHub, see "[About status checks](https://docs.github.com/articles/about-status-checks#checks)".',
    )

[yanyongyu]

It seems pydantic v1 uses min_items, max_items to restrict the list items count and min_length, max_length are used to restrict the str length.

[yanyongyu]

Maybe we need to add a custom Field in the compat module to handle the gap between v1 and v2.

[juantoca]

Thank you @yanyongyu for the fast response and for maintaining this library.

I've tried your proposal of changing the kwarg name to max_items and sadly the issue persists. I think this is related to pydantic/pydantic#3745 linked in the comment at _get_field_args. AFAIK, this was fixed in Pydantic V2 but it wasn't back-ported to V1. That's the reason why I'm proposing to disable completely the constraints on Pydantic V1 through the operator.

I understand that this is sub-optimal as we are effectively not respecting the JSON schema but I see no other option as the models have ForwardReferences that will break the implementation in V1. Fortunatly, V2 will be unaffected.

[yanyongyu]

i see the comments in the code. this issue has occured before when using pydantic v1, and was fixed when pydantic v2 released. i will change the comments to describe the problem better.

[yanyongyu]

I will add some test cases later.