Remove pytz dependency - #965
Conversation
|
Thanks @eagleoflqj. I appreciate the intent here, but I don’t think making pytz optional in drf-yasg is the right transition step. Optional dependencies with runtime effects add complexity and make behavior less predictable across environments. In this case, users who still rely on pytz specific behavior would also need to know to install pytz manually, which creates a hidden requirement and can lead to inconsistent results between setups. In #964, we removed a conditional optional import, which was a step in the right direction. Reintroducing conditional import logic for pytz now goes in the opposite direction. I understand the desire to avoid this dependency, but that is part of the tradeoff of using third-party libraries: they come with required dependencies. Changing this affects the broader user base, and stable, deterministic dependencies are better for everyone. My preference is to keep pytz required while pytz support is still part of the Django ecosystem, then announce deprecation clearly when it is time to remove it. Please correct me if I’ve misunderstood your proposal. |
A project I'm working on moved from pytz to zoneinfo, but can't drop the pytz dependency because drf-yasg depends on it. Turns out that drf-yasg doesn't rely on functionalities that pytz provides, but only checks if a parameter is of specific type. So this PR drops pytz as a dependency, and uses the same try import method that zoneinfo had (prior to #964), to preserve the behavior.