allenporter
Pydantic V2 support
Is your feature request related to a problem? Please describe. My models are all in pydantic V2. These cannot be intermixed with V1 models. Do you have plans to add support for v2 models?
Describe the solution you'd like
Optionally support V2 models in pydantic for Calendar, Event etc.
Describe alternatives you've considered Currently I have split V1 models separately, so I have a combination of both in the codebase.
Additional context
Hi -- appreciate reaching out here. Perhaps there are couple topics to unwind:
-
Use of pydantic in ical should be an implementation detail not really a feature that is consumed by the library. Can you explain how you're using the data model? I'm wondering if there is an alternative way the APIs could be exposed to make this easier (e.g. only exposing dataclasses and not inheriting pydantic models)
-
To more directly answer the question, the primary consumer of this library requires v1 and can't upgrade to v2 until many other libraries have been upgraded. For now, this continues to use the v1 stubs when v2 is installed for compatibility. I'm not sure there is a path forward without forking.
Given the pain that pydantic caused through its upgrade path to v2 (which is somewhat hostile), I'm more inclined to move away from pydantic and on to another libraries rather than add lots of workaround or duplicate the model hierarchy with both v1 and v2 models.
Happy to discuss and entertain other approaches. This library does not have that many consumers so its not super painful to make large changes.
TL;dr. This is not a blocker for me anymore, feel free to close the issue.
Hi, thanks for taking the time to respond. I’ll explain my use case. I am using pydantic V2 everywhere, and I was storing additional metadata in a struct along with the “calendar” object. I was using this to store the calendar along with the events, make modifications etc and keep it as the primary data source of the calendar. This is where I ran into some pain managing v1 and v2 in the code base simultaneously, and created this issue.
I have since moved away from that model, for other reasons than this issue. I am still using iCal but only to serialize to ICS rather than as the main data source. So this issue itself is not a blocker for me, please do feel free to close it.
On Sun, Mar 17, 2024 at 12:32 PM Allen Porter @.***> wrote:
Hi -- appreciate reaching out here. Perhaps there are couple topics to unwind:
Use of pydantic in ical should be an implementation detail not really a feature that is consumed by the library. Can you explain how you're using the data model? I'm wondering if there is an alternative way the APIs could be exposed to make this easier (e.g. only exposing dataclasses and not inheriting pydantic models) 2.
To more directly answer the question, the primary consumer of this library requires v1 and can't upgrade to v2 until many other libraries have been upgraded. For now, this continues to use the v1 stubs when v2 is installed for compatibility. I'm not sure there is a path forward without forking.
Given the pain that pydantic caused through its upgrade path to v2 (which is somewhat hostile), I'm more inclined to move away from pydantic and on to another libraries rather than add lots of workaround or duplicate the model hierarchy with both v1 and v2 models.
Happy to discuss and entertain other approaches. This library does not have that many consumers so its not super painful to make large changes.
— Reply to this email directly, view it on GitHub https://github.com/allenporter/ical/issues/310#issuecomment-2002590305, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMICTTOOZMODK7GC2HID3YYXVUNAVCNFSM6AAAAABEUY6V4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGU4TAMZQGU . You are receiving this because you authored the thread.Message ID: @.***>
@allenporter I understand that Pydantic 2.0 migration is annoying, but I use this library mainly to serialize ics files to JSON so I can dump it into a database. 😄 So using Pydantic as the serialization backend is perfect for me.
Plus, really not a fan of the other 2 alternatives in the Python ecosystem. ics.py is untyped, makes a few weird decisions like using set()s in inappropriate places, and doesn't serialize to JSON well; icalendar among other issues isn't even fully RFC 5545 compliant and thus it causes issues in my data pipeline for perfectly valid ics files.
If you need help with any Pydantic migration work, let me know. My use case essentially requires Pydantic and I hope you consider keeping it, and I can chip in if you need resources to keep using Pydantic.
I could definitely use help on pedantic migration. However I need to use this library in code based that don't yet support v2 (home assistant). Given pydantic made this weird upgrade choice I'm not sure what we can do in the mean time.
So maybe the most helpful thing is to upgrade all home assistant dependencies to v2 with v1 stubs :) it's made progress though so it's not starting from nothing.
Agree with your assessments of the choices of other libraries, that prompted me to make this library.
This library now requires pydantic 2 or greater. This library uses the v1 stubs, but it shouldn't be holding back any other use of v2 anymore.
I'll likely move away from pydantic entirely in the future and on to something simpler. For folks thinking about doing anything fancy, keep in mind that pydantic should be treated as an implementation detail of this library and is not part of the public API and can break at any time.
I'm going to close given this is no longer blocking any other use of v2.