cadwyn 5.4.5__tar.gz → 5.6.0__tar.gz

{cadwyn-5.4.5 → cadwyn-5.6.0}/CHANGELOG.md

@@ -5,6 +5,26 @@ Please follow [the Keep a Changelog standard](https://keepachangelog.com/en/1.0.
 
 ## [Unreleased]
 
+## [5.6.0]
+
+### Added
+
+* `schema(...).had(json_schema_extra=...)` support by @csemanish12
+
+## [5.5.0]
+
+* Fix the rest of the issues from fastapi==0.119.0
+
+## [5.4.5]
+
+### Fixed
+
+* Many issues after GenerateJsonSchema getting removed in fastapi==0.119.0
+
+### Changed
+
+* A lot of documentation improvements by @Shigerman
+
 ## [5.4.4]
 
 ### Fixed
@@ -33,9 +53,8 @@ Please follow [the Keep a Changelog standard](https://keepachangelog.com/en/1.0.
 
 ### Added
 
-- `typing_inspection` dependency from pydantic team for complex isinstance checks that must be the same between `typing` and `typing_extensions`
-- Support for `pydantic>=2.12.0` FieldInfo refactoring from https://github.com/pydantic/pydantic/pull/11898
-
+* `typing_inspection` dependency from pydantic team for complex isinstance checks that must be the same between `typing` and `typing_extensions`
+* Support for `pydantic>=2.12.0` FieldInfo refactoring from <https://github.com/pydantic/pydantic/pull/11898>
 
 ## [5.3.3]
 

{cadwyn-5.4.5 → cadwyn-5.6.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cadwyn
-Version: 5.4.5
+Version: 5.6.0
 Summary: Production-ready community-driven modern Stripe-like API versioning in FastAPI
 Project-URL: Source code, https://github.com/zmievsa/cadwyn
 Project-URL: Documentation, https://docs.cadwyn.dev
@@ -35,14 +35,14 @@ Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Classifier: Typing :: Typed
 Requires-Python: >=3.9
 Requires-Dist: backports-strenum<2,>=1.3.1; python_version < '3.11'
-Requires-Dist: fastapi>=0.112.4
+Requires-Dist: fastapi>=0.119.0
 Requires-Dist: jinja2>=3.1.2
 Requires-Dist: pydantic>=2.11.0
 Requires-Dist: starlette>=0.30.0
 Requires-Dist: typing-extensions>=4.8.0
 Requires-Dist: typing-inspection>=0.4.0
 Provides-Extra: standard
-Requires-Dist: fastapi[standard]>=0.112.3; extra == 'standard'
+Requires-Dist: fastapi[standard]>=0.119.0; extra == 'standard'
 Requires-Dist: typer>=0.7.0; extra == 'standard'
 Description-Content-Type: text/markdown
 

{cadwyn-5.4.5 → cadwyn-5.6.0}/cadwyn/changelogs.py

@@ -2,9 +2,13 @@ import copy
 import sys
 from enum import auto
 from logging import getLogger
-from typing import TYPE_CHECKING, Any, Literal, TypeVar, Union, cast, get_args
+from typing import Any, Literal, TypeVar, Union, cast, get_args
 
-from fastapi.openapi.constants import REF_TEMPLATE
+from fastapi._compat import (
+    get_compat_model_name_map,
+    get_definitions,
+)
+from fastapi._compat.v2 import ModelField
 from fastapi.openapi.utils import (
     get_fields_from_routes,
     get_openapi,
@@ -35,9 +39,6 @@ from .structure.schemas import (
     ValidatorExistedInstruction,
 )
 
-if TYPE_CHECKING:
-    from fastapi._compat import ModelField
-
 if sys.version_info >= (3, 11):  # pragma: no cover
     from enum import StrEnum
 else:  # pragma: no cover
@@ -89,7 +90,7 @@ def _generate_changelog(versions: VersionBundle, router: _RootCadwynAPIRouter) -
                     version_change,
                     generator_from_newer_version,
                     generator_from_older_version,
-                    schemas_from_older_version,
+                    schemas_from_older_version,  # pyright: ignore[reportArgumentType]
                     cast("list[APIRoute]", routes_from_newer_version),
                 )
                 if changelog_entry is not None:  # pragma: no branch # This should never happen
@@ -153,21 +154,22 @@ def _get_all_pydantic_models_from_generic(annotation: Any) -> list[type[BaseMode
 
 
 def _get_openapi_representation_of_a_field(model: type[BaseModel], field_name: str) -> dict:
-    from fastapi._compat import (
-        GenerateJsonSchema,
-        ModelField,
-        get_compat_model_name_map,
-        get_definitions,
-    )
-
     class CadwynDummyModelForRepresentation(BaseModel):
         my_field: model
 
-    model_name_map = get_compat_model_name_map([CadwynDummyModelForRepresentation.model_fields["my_field"]])
-    schema_generator = GenerateJsonSchema(ref_template=REF_TEMPLATE)
+    model_name_map = get_compat_model_name_map(
+        [
+            CadwynDummyModelForRepresentation.model_fields["my_field"],  # pyright: ignore[reportArgumentType]
+        ]
+    )
+
     _, definitions = get_definitions(
-        fields=[ModelField(CadwynDummyModelForRepresentation.model_fields["my_field"], "my_field")],
-        schema_generator=schema_generator,
+        fields=[
+            ModelField(
+                CadwynDummyModelForRepresentation.model_fields["my_field"],
+                "my_field",
+            ),  # pyright: ignore[reportArgumentType]
+        ],
         model_name_map=model_name_map,
         separate_input_output_schemas=False,
     )

{cadwyn-5.4.5 → cadwyn-5.6.0}/cadwyn/structure/schemas.py

@@ -58,6 +58,7 @@ PossibleFieldAttributes = Literal[
     "allow_mutation",
     "pattern",
     "discriminator",
+    "json_schema_extra",
 ]
 
 
@@ -100,6 +101,7 @@ class FieldChanges:
     allow_mutation: bool
     pattern: str
     discriminator: str
+    json_schema_extra: Union[dict[str, Any], Callable[[dict[str, Any]], None], None]
 
 
 @dataclass(**DATACLASS_SLOTS)
@@ -178,6 +180,7 @@ class AlterFieldInstructionFactory:
         allow_mutation: bool = Sentinel,
         pattern: str = Sentinel,
         discriminator: str = Sentinel,
+        json_schema_extra: Union[dict[str, Any], Callable[[dict[str, Any]], None], None] = Sentinel,
     ) -> FieldHadInstruction:
         return FieldHadInstruction(
             is_hidden_from_changelog=False,
@@ -222,6 +225,7 @@ class AlterFieldInstructionFactory:
                 allow_mutation=allow_mutation,
                 pattern=pattern,
                 discriminator=discriminator,
+                json_schema_extra=json_schema_extra,
             ),
         )
 

{cadwyn-5.4.5 → cadwyn-5.6.0}/docs/concepts/version_changes.md

@@ -132,12 +132,12 @@ In Cadwyn, you use the latest version. This attribute is a way for you to descri
 
 This approach of *maintaining the present and describing the past* might appear weird. You just need to form the correct mindset which is counter-intuitive at first but after just one or two attempts at versioning you will see how much sense this approach makes.
 
-Imagine you needed to know what your code looked like two weeks ago. You would use `git checkout` or `git reset` with an older commit because `git` stores the latest version of your code (which is also called HEAD) and the diffs between it and each previous version as a chain of changes. This is exactly how Cadwyn works! We store the latest version and use the diffs to regenerate the older versions.
+Imagine you need to know what your code looked like two weeks ago. You would use `git checkout` or `git reset` with an older commit because `git` stores the latest version of your code (which is also called HEAD) and the diffs between it and each previous version as a chain of changes. This is exactly how Cadwyn works! We store the latest version and use the diffs to regenerate the older versions.
 
 <details>
   <summary>Note to curious readers</summary>
 
-  Git doesn't actually work this way internally. My description is closer to how SVN works. It is just a really simplistic metaphor to explain a concept.
+  Git doesn't actually work this way internally. My description is closer to how SVN works. It is just a really simple metaphor to explain a concept.
 </details>
 
 ### Data migrations
@@ -167,7 +167,7 @@ class RemoveTaxIdEndpoints(VersionChange):
         request.body["created_at"] = request.body.pop("creation_date")
 ```
 
-Did you notice how the schema for `InvoiceCreateRequest` is specified in our migration? This will signal to Cadwyn to apply it to all routes that have this schema as their body.
+Did you notice how the schema for `InvoiceCreateRequest` is specified in our migration? This signals Cadwyn to apply it to all routes with this schema as their body.
 
 Now we have not only described how schemas changed but we have also described how to migrate a request of the old version to the new version. When Cadwyn receives a request targeting a particular version, the request is first validated against the schema of that particular version. Then Cadwyn applies all request migrations until the latest version to migrate the request to latest. So now your business logic receives the latest version of the request yet for your clients you have two versions of your API -- you have added variability without introducing any complexity into your business logic.
 
@@ -204,13 +204,13 @@ class RemoveTaxIdEndpoints(VersionChange):
         response.body["creation_date"] = response.body.pop("created_at")
 ```
 
-Did you notice how the schema for `InvoiceResource` is specified in our migration? This will signal to Cadwyn to apply it to all routes that have this schema as their `response_model`. Notice also that we now use `BaseInvoice` in our instructions -- let's imagine that it is the parent of both `InvoiceCreateRequest` and `InvoiceResource` so renaming it there will rename it in these schemas as well. You can, however, apply the instructions to both individual schemas instead of their parent if you want to.
+Did you notice how the schema for `InvoiceResource` is specified in our migration? This signals Cadwyn to apply it to all routes with this schema as their `response_model`. Notice also that we now use `BaseInvoice` in our instructions -- imagine it is the parent of both `InvoiceCreateRequest` and `InvoiceResource` so renaming it there will rename it in these schemas as well. You can, however, apply the instructions to both individual schemas instead of their parent if you want to.
 
-Now our request comes, Cadwyn migrates it to the latest version using our request migration, then we do our business logic, return the latest response from it, and Cadwyn migrates it back to the request version. Does our business logic or database know about the fact that we have two versions? No, not at all! It is zero-cost. Imagine how beneficial it is when you support not two but two hundred versions.
+Now our request comes, Cadwyn migrates it to the latest version using our request migration, then we do our business logic, return the latest response from it, and Cadwyn migrates it back to the request version. Does our business logic or database know about the fact that we have two versions? No, not at all! It is zero-cost. Consider the benefits of supporting not just two, but two hundred versions.
 
 ![The diagram showing how it works](../img/simplified_migration_model.png)
 
-**Notice** how we used the **latest** versions of our schemas in our migration -- this pattern can be found everywhere in Cadwyn. The latest version of your schemas is used to describe what happened to all other versions because other versions might not exist when you are defining migrations for them.
+**Notice** how the **latest** versions of our schemas are used in our migration -- this pattern can be found everywhere in Cadwyn. The latest version of your schemas is used to describe what happened to all other versions because other versions might not exist when you are defining migrations for them.
 
 #### Path-based migration specification
 
@@ -260,13 +260,13 @@ from cadwyn import (
 
 
 class RemoveTaxIdEndpoints(VersionChange):
-    description = "Change status code in 'GET /v1/invoices' when invoice was not found from 400 to 404"
+    description = "Replace status code 400 with 404 in 'GET /v1/invoices' if invoice is not found"
     instructions_to_migrate_to_previous_version = ()
 
     @convert_response_to_previous_version_for(
         "/v1/invoices", ["GET"], migrate_http_errors=True
     )
-    def change_400_to_404(response: ResponseInfo):
+    def replace_400_with_404(response: ResponseInfo):
         if response.status_code == 400:
             response.status_code = 404
 ```
@@ -292,9 +292,9 @@ Cadwyn can migrate more than just request bodies.
 
 #### Internal representations
 
-We have only reviewed simplistic cases so far. But what happens when you cannot just migrate your data that easily? It can happen because your earlier versions had **more data** than your newer versions. Or that data had more formats.
+We have only reviewed simple cases so far. But what happens when you cannot just migrate your data that easily? It can happen because your earlier versions had **more data** than your newer versions. Or that data had more formats.
 
-Let's imagine that previously the `User` schema had a list of addresses but now we want to make a breaking change and turn them into a single address. The naive migration will just take the first address from the list for requests and turn that one address into a list for responses like so:
+Imagine that previously the `User` schema had a list of addresses but now we want to make a breaking change and turn them into a single address. The naive migration will just take the first address from the list for requests and turn that address into a list for responses like so:
 
 ```python
 from cadwyn import (
@@ -328,7 +328,7 @@ class RemoveTaxIdEndpoints(VersionChange):
         response.body["addresses"] = [response.body.pop("address")]
 ```
 
-But this will not work. Now when the user from the old version asks us to save three addresses, we will in fact save only one. Old data is also going to be affected -- if old users had multiple addresses, we will only be able to return one of them. This is bad -- we have made a breaking change!
+But this will not work. If the user from the old version requests to save three addresses, only one will actually be saved. Old data is also going to be affected -- if old users had multiple addresses, we will only be able to return one of them. This is bad -- we have made a breaking change!
 
 In order to solve this issue, Cadwyn uses a concept of **internal representations**. An internal representation of your data is like a database entry of your data -- it is its **latest** version plus all the fields that are incompatible with the latest API version. If we were talking about classes, then internal representation would be a child of your latest schemas -- it has all the same data and a little more, it expands its functionality. Essentially your internal representation of user object can contain much more data than your latest schemas.
 
@@ -357,11 +357,11 @@ class RemoveTaxIdEndpoints(VersionChange):
     )
 ```
 
-Yes, we do not need any of the migrations anymore because responses are handled automatically. See how-to section for an example of how we would achieve the same feat for requests.
+Yes, we do not need any of the migrations anymore because responses are handled automatically. See the how-to section for an example of achieving the same result with requests.
 
 #### Manual body migrations
 
-Oftentimes you will have a need to migrate your data outside of routing, manually. For example, when you need to send a versioned response to your client via webhook or inside a worker/cronjob. In these instances, you can use `cadwyn.VersionBundle.migrate_response_body`:
+Oftentimes you will need to migrate your data outside of routing, manually. For example, when you need to send a versioned response to your client via webhook or inside a worker/cronjob. In these instances, you can use `cadwyn.VersionBundle.migrate_response_body`:
 
 ```python
 from users import UserResource

cadwyn-5.6.0/docs/home/CONTRIBUTING.md

@@ -0,0 +1,71 @@
+# Contribution Guide
+
+## Setting up the environment
+
+* The minimum supported version is Python 3.10. It is recommended to manage multiple Python versions on your system with [uv](https://docs.astral.sh/uv/)
+* We maintain a Makefile with several commands to help with common tasks
+
+1. Install [uv](https://docs.astral.sh/uv/)
+2. Run `uv sync` to create a virtual environment and install the dependencies
+3. Install [pre-commit](https://pre-commit.com/) using uv: `uv tool install pre-commit`
+4. Run `pre-commit install --install-hooks` to install pre-commit hooks
+
+## Code contributions
+
+### Workflow
+
+1. [Fork](https://github.com/zmievsa/cadwyn/fork) the [Cadwyn repository](https://github.com/zmievsa/cadwyn)
+2. Clone your fork locally with git
+3. [Set up the environment](#setting-up-the-environment)
+4. Make your changes
+5. Commit your changes to git
+6. Push the changes
+7. Open a [pull request](https://docs.github.com/en/pull-requests). Give the pull request a descriptive title indicating what was changed
+
+## Guidelines for writing code
+
+* Code should be [Pythonic and zen](https://peps.python.org/pep-0020/)
+* All code should be fully [typed](https://peps.python.org/pep-0484/). This is enforced via [ruff](https://github.com/astral-sh/ruff) but the type hinting itself will be enforced by [pyright](https://github.com/microsoft/pyright/) in the future
+  * When complex types are required, use [type aliases](https://docs.python.org/3/library/typing.html#type-aliases)
+  * If something cannot be typed correctly due to the limitations of the type checkers, use [typing.cast](https://docs.python.org/3/library/typing.html#typing.cast) to resolve the issue. However, use `typing.cast` only as a last resort, after exhausting all other options of [type narrowing](https://mypy.readthedocs.io/en/stable/type_narrowing.html), such as [isinstance()](https://docs.python.org/3/library/functions.html#isinstance) checks and [type guards](https://docs.python.org/3/library/typing.html#typing.TypeGuard)
+  * Use `pyright: ignore` once you have verified that the line is correct, but pyright has issues with it
+* If you are adding or modifying existing code, make sure that it's fully tested. 100% test coverage is mandatory, and will be checked on the PR using [Github Actions](https://github.com/features/actions)
+* When adding a new public interface, make sure you have included it in the concept documentation located in `docs/concepts.md`. If applicable, add or modify examples in the docs related to the new functionality
+
+### Writing and running tests
+
+Tests are contained within the `tests` directory, and follow roughly the same
+directory structure as the `cadwyn` module. If you are adding a test
+case, it should be located within the correct submodule of `tests`. E.g.
+tests for `cadwyn/codegen.py` reside in `tests/codegen`.
+
+`make test` to run tests located in `tests`
+
+### Running type checkers
+
+We use [pyright](https://github.com/microsoft/pyright/) to enforce type safety.
+You can run it with:
+
+`uv run pyright .`
+
+## Project documentation
+
+The documentation is located in the `/docs` directory and uses
+[Markdown](https://www.markdownguide.org/).
+
+### Docs theme and appearance
+
+We welcome contributions that improve the appearance and usability of the docs. We use [mkdocs-material](https://squidfunk.github.io/mkdocs-material/) If you wish to contribute to the docs style / setup, or static site generation, consult the theme docs as a first step.
+
+### Running the docs locally
+
+After improving the docs, serve the documentation with `mkdocs serve`
+
+### Writing and editing docs
+
+We welcome contributions that improve the content of the docs. Feel free to add examples, clarify text, restructure the docs, etc., but make sure to follow these guidelines:
+
+* Write text in idiomatic, simple English
+* Opt for [Oxford commas](https://en.wikipedia.org/wiki/Serial_comma) when listing a series of terms
+* Keep examples simple and self contained
+* Provide links where applicable

cadwyn-5.6.0/docs/how_to/change_business_logic/index.md

@@ -0,0 +1,28 @@
+
+# Change the business logic in a new version
+
+First, ask yourself: are you sure a behavioral change is really necessary? Are you sure it is not possible to keep the same logic for both versions? Or at least make the behavior depend on the received data? Behavioral changes (or **side effects**) are the least maintainable part of almost any versioning approach. They produce the largest footprint on your code. So if you are not careful, your logic will be littered with version checks.
+
+But if you are certain that you need to make a breaking behavioral change, Cadwyn has all the tools to minimize its impact as much as possible.
+
+## Calling endpoint causes unexpected data modifications
+
+Use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).
+
+## Calling endpoint doesn't cause expected data modifications
+
+Use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).
+
+## Calling endpoint doesn't cause expected additional actions (e.g. Webhooks)
+
+Use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).
+
+## Errors
+
+### Change the status code or a message in an HTTP error
+
+You can [migrate anything about the error](../../concepts/version_changes.md#migration-of-http-errors) in a version change.
+
+### Introduce a new error or remove an old error
+
+Use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).

{cadwyn-5.4.5 → cadwyn-5.6.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "cadwyn"
-version = "5.4.5"
+version = "5.6.0"
 description = "Production-ready community-driven modern Stripe-like API versioning in FastAPI"
 authors = [{ name = "Stanislav Zmiev", email = "zmievsa@gmail.com" }]
 license = "MIT"
@@ -51,7 +51,7 @@ classifiers = [
     "Topic :: Internet :: WWW/HTTP",
 ]
 dependencies = [
-    "fastapi >=0.112.4",
+    "fastapi >=0.119.0",
     "starlette >=0.30.0",
     "pydantic >=2.11.0",
     "jinja2 >=3.1.2",
@@ -62,7 +62,7 @@ dependencies = [
 
 
 [project.optional-dependencies]
-standard = ["fastapi[standard]>=0.112.3", "typer>=0.7.0"]
+standard = ["fastapi[standard]>=0.119.0", "typer>=0.7.0"]
 
 [tool.uv]
 dev-dependencies = [

{cadwyn-5.4.5 → cadwyn-5.6.0}/tests/test_render.py

@@ -10,8 +10,6 @@ from cadwyn.structure.versions import Version, VersionBundle
 from tests.test_cli import code
 
 
-# TODO: Return this test once https://github.com/pydantic/pydantic/pull/11898 is merged
-@pytest.mark.xfail
 def test__render_model__with_weird_types():
     result = render_model_by_path(
         "tests._resources.render.complex.classes:ModelWithWeirdFields",

{cadwyn-5.4.5 → cadwyn-5.6.0}/tests/test_schema_generation/test_schema_field.py

@@ -10,6 +10,7 @@ from cadwyn.exceptions import (
     CadwynStructureError,
     InvalidGenerationInstructionError,
 )
+from cadwyn.schema_generation import SchemaGenerator
 from cadwyn.structure import schema
 from tests.conftest import (
     CreateRuntimeSchemas,
@@ -68,16 +69,17 @@ def test__field_existed_as__original_schema_has_a_field(create_runtime_schemas:
 
 
 def test__field_existed_as__extras_are_added(create_runtime_schemas: CreateRuntimeSchemas):
-    schemas = create_runtime_schemas(
-        version_change(
-            schema(EmptySchema)
-            .field("foo")
-            .existed_as(
-                type=int,
-                info=Field(deflolbtt="hewwo"),  # pyright: ignore[reportCallIssue]
-            ),
+    with pytest.warns(DeprecationWarning):
+        schemas = create_runtime_schemas(
+            version_change(
+                schema(EmptySchema)
+                .field("foo")
+                .existed_as(
+                    type=int,
+                    info=Field(deflolbtt="hewwo"),  # pyright: ignore[reportCallIssue]
+                ),
+            )
         )
-    )
 
     class ExpectedSchema(BaseModel):
         foo: int = Field(json_schema_extra={"deflolbtt": "hewwo"})
@@ -180,7 +182,7 @@ def assert_field_had_changes_apply(
     attr: str,
     attr_value: Any,
     create_runtime_schemas: CreateRuntimeSchemas,
-):
+) -> dict[str, SchemaGenerator]:
     schemas = create_runtime_schemas(version_change(schema(model).field("foo").had(**{attr: attr_value})))
 
     field_info = schemas["2000-01-01"][model].model_fields["foo"]
@@ -190,6 +192,8 @@ def assert_field_had_changes_apply(
     else:
         assert getattr(field_info, attr) == attr_value
 
+    return schemas
+
 
 @pytest.mark.parametrize(
     ("attr", "attr_value"),
@@ -266,7 +270,7 @@ def test__schema_field_had__decimal_field(attr: str, attr_value: Any, create_run
 
 @pytest.mark.parametrize(
     ("attr", "attr_value"),
-    [("exclude", [16, 17, 18])],
+    [("exclude", True)],
 )
 def test__schema_field_had__list_of_int_field(attr: str, attr_value: Any, create_runtime_schemas: CreateRuntimeSchemas):
     class SchemaWithOneListOfIntField(BaseModel):
@@ -294,6 +298,46 @@ def test__schema_field_had__float_field(
     )
 
 
+def test_schema_field_had__json_schema_extra_as_dict(create_runtime_schemas: CreateRuntimeSchemas):
+    class SchemaWithFooHadDictJsonSchemaExtra(BaseModel):
+        foo: str
+
+    schemas = assert_field_had_changes_apply(
+        SchemaWithFooHadDictJsonSchemaExtra,
+        "json_schema_extra",
+        {"example": "bar"},
+        create_runtime_schemas,
+    )
+
+    # Validate the JSON Schema produced by Pydantic contains the extra
+    model_cls = schemas["2000-01-01"][SchemaWithFooHadDictJsonSchemaExtra]  # pyright: ignore
+    json_schema = model_cls.model_json_schema()
+    assert json_schema["properties"]["foo"]["example"] == "bar"
+
+
+def test__schema_field_had__json_schema_extra_as_callable(create_runtime_schemas: CreateRuntimeSchemas):
+    def modify_schema(schema_dict: dict[str, Any]):
+        schema_dict["example"] = "bar"
+        schema_dict["custom"] = 42
+
+    class SchemaWithFooHadCallableJsonSchemaExtra(BaseModel):
+        foo: str
+
+    schemas = assert_field_had_changes_apply(
+        SchemaWithFooHadCallableJsonSchemaExtra,
+        "json_schema_extra",
+        modify_schema,
+        create_runtime_schemas,
+    )
+
+    # Validate the JSON Schema produced by Pydantic contains changes from the callable
+    model_cls = schemas["2000-01-01"][SchemaWithFooHadCallableJsonSchemaExtra]  # pyright: ignore
+    json_schema = model_cls.model_json_schema()
+    props = json_schema["properties"]["foo"]
+    assert props["example"] == "bar"
+    assert props["custom"] == 42
+
+
 def test__schema_field_didnt_have__removing_default(create_runtime_schemas: CreateRuntimeSchemas):
     class SchemaWithDefaults(BaseModel):
         foo: str = "hewwo"

{cadwyn-5.4.5 → cadwyn-5.6.0}/uv.lock

@@ -99,7 +99,7 @@ wheels = [
 
 [[package]]
 name = "cadwyn"
-version = "5.4.5"
+version = "5.6.0"
 source = { editable = "." }
 dependencies = [
     { name = "backports-strenum", marker = "python_full_version < '3.11'" },
@@ -144,8 +144,8 @@ dev = [
 [package.metadata]
 requires-dist = [
     { name = "backports-strenum", marker = "python_full_version < '3.11'", specifier = ">=1.3.1,<2" },
-    { name = "fastapi", specifier = ">=0.112.4" },
-    { name = "fastapi", extras = ["standard"], marker = "extra == 'standard'", specifier = ">=0.112.3" },
+    { name = "fastapi", specifier = ">=0.119.0" },
+    { name = "fastapi", extras = ["standard"], marker = "extra == 'standard'", specifier = ">=0.119.0" },
     { name = "jinja2", specifier = ">=3.1.2" },
     { name = "pydantic", specifier = ">=2.11.0" },
     { name = "starlette", specifier = ">=0.30.0" },

cadwyn-5.4.5/docs/home/CONTRIBUTING.md

@@ -1,72 +0,0 @@
-# Contribution Guide
-
-## Setting up the environment
-
-* The lowest currently supported version is Python 3.10. You should use
-[uv](https://docs.astral.sh/uv/) to manage multiple Python
-versions on your system.
-* We maintain a Makefile with several commands to help with common tasks.
-
-1. Install [uv](https://docs.astral.sh/uv/)
-2. Run `uv sync` to create a virtual environment and install the required development dependencies
-3. Install [pre-commit](https://pre-commit.com/) using uv: `uv tool install pre-commit`
-4. Run `pre-commit install --install-hooks` to install pre-commit hooks
-
-## Code contributions
-
-### Workflow
-
-1. [Fork](https://github.com/zmievsa/cadwyn/fork) the [Cadwyn repository](https://github.com/zmievsa/cadwyn)
-2. Clone your fork locally with git
-3. [Set up the environment](#setting-up-the-environment)
-4. Make your changes
-5. Commit your changes to git.
-6. Open a [pull request](https://docs.github.com/en/pull-requests). Give the pull request a descriptive title indicating what it changes.
-
-## Guidelines for writing code
-
-* Code should be [Pythonic and zen](https://peps.python.org/pep-0020/)
-* All code should be fully [typed](https://peps.python.org/pep-0484/). This is enforced via [ruff](https://github.com/astral-sh/ruff) but the type hinting itself will be enforced by [pyright](https://github.com/microsoft/pyright/) in the future.
-  * When requiring complex types, use a [type alias](https://docs.python.org/3/library/typing.html#type-aliases).
-  * If something cannot be typed correctly due to a limitation of the type checkers, you may use [typing.cast](https://docs.python.org/3/library/typing.html#typing.cast) to rectify the situation. However, you should only use as a last resort if you've exhausted all other options of [type narrowing](https://mypy.readthedocs.io/en/stable/type_narrowing.html), such as [isinstance()](https://docs.python.org/3/library/functions.html#isinstance) checks and [type guards](https://docs.python.org/3/library/typing.html#typing.TypeGuard)
-  * You may use `pyright: ignore` if you ensured that a line is correct, but pyright has issues with it.
-* If you are adding or modifying existing code, ensure that it's fully tested. 100% test coverage is mandatory, and will be checked on the PR using [Github Actions](https://github.com/features/actions)
-* When adding a new public interface, it has to be included in the concept documentation located in `docs/concepts.md`. If applicable, add or modify examples in the docs related to the new functionality implemented.
-
-### Writing and running tests
-
-Tests are contained within the `tests` directory, and follow roughly the same
-directory structure as the `cadwyn` module. If you are adding a test
-case, it should be located within the correct submodule of `tests`. E.g.
-tests for `cadwyn/codegen.py` reside in `tests/codegen`.
-
-`make test` to run tests located in `tests`
-
-### Running type checkers
-
-We use [pyright](https://github.com/microsoft/pyright/) to enforce type safety.
-You can run it with:
-
-`uv run pyright .`
-
-## Project documentation
-
-The documentation is located in the `/docs` directory and is all in
-[Markdown](https://www.markdownguide.org/).
-
-### Docs theme and appearance
-
-We welcome contributions that enhance / improve the appearance and usability of the docs. We use [mkdocs-material](https://squidfunk.github.io/mkdocs-material/) If you wish to contribute to the docs style / setup, or static site generation, you should consult the theme docs as a first step.
-
-### Running the docs locally
-
-Then you can serve the documentation with `mkdocs serve`
-
-### Writing and editing docs
-
-We welcome contributions that enhance / improve the content of the docs. Feel free to add examples, clarify text, restructure the docs, etc., but make sure to follow these guidelines:
-
-* Write text in idiomatic English, using simple language
-* Opt for [Oxford commas](https://en.wikipedia.org/wiki/Serial_comma) when listing a series of terms
-* Keep examples simple and self contained
-* Provide links where applicable

cadwyn-5.4.5/docs/how_to/change_business_logic/index.md

@@ -1,28 +0,0 @@
-
-# Change the business logic in a new version
-
-First, ask yourself: are you sure there really needs to be a behavioral change? Are you sure it is not possible to keep the same logic for both versions? Or at least make the behavior depend on the received data? Behavioral changes (or **side effects**) are the least maintainable part of almost any versioning approach. They produce the largest footprint on your code so if you are not careful -- your logic will be littered with version checks.
-
-But if you are certain that you need to make a breaking behavioral change, Cadwyn has all the tools to minimize its impact as much as possible.
-
-## Calling endpoint causes unexpected data modifications
-
-You'd use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).
-
-## Calling endpoint doesn't cause expected data modifications
-
-You'd use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).
-
-## Calling endpoint doesn't cause expected additional actions (e.g. Webhooks)
-
-You'd use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).
-
-## Errors
-
-### Change the status code or a message in an HTTP error
-
-You can [migrate anything about the error](../../concepts/version_changes.md#migration-of-http-errors) in a version change.
-
-### Introduce a new error or remove an old error
-
-You'd use an `if statement` with a [side effect](../../concepts/version_changes.md#version-changes-with-side-effects).