Relax pydantic pin from ==2.12.5 to >=2.12.5,<3 to allow distribution packaging

[mtritz]

Context

snowflake-cli currently pins pydantic==2.12.5 exactly in pyproject.toml. This is fine for standard pip/uv installs where pydantic is installed in an isolated environment.

However, it blocks packaging in distributions that manage Python dependencies globally (nixpkgs, Debian, Fedora, etc.), where pydantic is a shared package at a different version. nixpkgs currently ships pydantic 2.13.4, which makes it impossible to package snowflake-cli without either:

• Overriding pydantic to 2.12.5 system-wide (breaks other packages depending on 2.13+)
• Keeping snowflake-cli stuck at 3.13.1 (last version compatible without override)

Root cause

UpdatableModel.__init_subclass__ dynamically injects field_validator(mode="wrap") validators via setattr. This mechanism breaks with pydantic >= 2.13 due to a behavioral change in how dynamically added wrap validators interact with statically declared before/after validators on the same field.

The failing tests (all in tests/api/project/schemas/test_updatable_model.py) confirm this is a compatibility issue with pydantic >= 2.13, not a general breakage.

Request

Either:

1. Relax the pin to pydantic>=2.12.5,<3 and fix the pydantic 2.13 compatibility in UpdatableModel — this would unblock distribution packaging and future pydantic upgrades.

2. Or document that the exact pin is intentional and pydantic 2.13+ is not supported, so distributions know to keep the override.

Impact

Discovered while updating the nixpkgs snowflake-cli package from 3.13.1 to 3.22.1. The bump is blocked until this is resolved.

[RogueAlg0]

Hi, I'd like to take this one on.

From reading the issue: the pin itself is the smaller half. The real work is the pydantic 2.13 incompatibility in UpdatableModel.init_subclass, where the dynamically injected wrap validators clash with statically declared before/after validators on the same field. The failing tests in tests/api/project/schemas/test_updatable_model.py already pin down the breakage, which is a good starting point.

My plan would be:

1. Reproduce the failures with pydantic 2.13.x installed.
2. Fix the validator injection in UpdatableModel so it works on both 2.12 and 2.13.
3. Relax the pin to pydantic>=2.12.5,<3 in pyproject.toml.
4. Run the test suite against both pydantic versions.

Does option 1 (fix the compatibility plus relax the pin) still sound like the preferred direction, or would you rather keep the exact pin and document it as intentional?