Hi Mixpanel team! While auditing our Docker image we noticed that mixpanel is the only package in our Django app's dependency tree that pulls in pydantic. It's used only in mixpanel/flags/types.py to define some DTOs for the new feature flags API. Great to see flags support in Mixpanel, but the packaging cost seems disproportionate to what pydantic is doing there:
- The whole pydantic chain adds almost 10 MB to our image.
pydantic-core is a compiled Rust extension, so the SDK is no longer pure Python: platform-specific wheels, and lag on new CPython releases, something that has bitten us before.- Pydantic is one of the most aggressively pinned packages in the ecosystem, so requiring it unconditionally exposes applications to dependency resolution conflicts.
mixpanel/__init__.py imports the flags module at top level, so import mixpanel pulls in pydantic (and httpx) even for apps that only call track().
The models themselves don't use validators, coercion, or aliases, just typed fields with defaults, and the payloads come from Mixpanel's own API, so stdlib dataclasses would seem to cover the current usage.
Unless there are plans to lean on pydantic's validation more heavily, would you be open to replacing the pydantic models with plain dataclasses or making flags support an extra (as in pip install mixpanel[flags])?
I would be happy to send a PR if there's interest. Thank you for your time.
Hi Mixpanel team! While auditing our Docker image we noticed that
mixpanelis the only package in our Django app's dependency tree that pulls in pydantic. It's used only inmixpanel/flags/types.pyto define some DTOs for the new feature flags API. Great to see flags support in Mixpanel, but the packaging cost seems disproportionate to what pydantic is doing there:pydantic-coreis a compiled Rust extension, so the SDK is no longer pure Python: platform-specific wheels, and lag on new CPython releases, something that has bitten us before.mixpanel/__init__.pyimports the flags module at top level, soimport mixpanelpulls in pydantic (and httpx) even for apps that only calltrack().The models themselves don't use validators, coercion, or aliases, just typed fields with defaults, and the payloads come from Mixpanel's own API, so stdlib dataclasses would seem to cover the current usage.
Unless there are plans to lean on pydantic's validation more heavily, would you be open to replacing the
pydanticmodels with plain dataclasses or making flags support an extra (as inpip install mixpanel[flags])?I would be happy to send a PR if there's interest. Thank you for your time.