potiuk commented on PR #51059:
URL: https://github.com/apache/airflow/pull/51059#issuecomment-2976597260

   > > We are slowly getting there. I do prefer a refactor, so that classname 
isn't there anymore. Otherwise we just have redundant code and tech debt.
   > 
   > Thanks for the feedback! I was a little hesitated since it will be a huge 
refactor. I totally agree with your point, and will gradually refactor those. I 
would start with the `serde.py`, and once we are good on the overall structure, 
will update submodule to follow the general structure.
   
   Also - if we are thinking about refactoring stuff. I think (and I know 
@bolkedebruin had other opinion on that) - there  was a discussion on whether 
depending on other dependencies (say pandas, deltalake, iceberg, kubernetes)   
which are part of the "core" airflow - but also we have "providers" for many of 
those that provide operators / hooks and other "core extensions" related to the 
respective "external entity".
   
   In my view, serializers for kubernetes, should come from kubernetes 
provider. Deltalake -> should come from databricks (or deltalake provider if we 
decide to have one), iceber should come from iceberg provider.
   
   Again -> I know @bolkedebruin had different view on that, but my goal is to 
have core as small as possible, and add anything to it as "extensions" - for 
which we already have "providers" as a mechanism to do so.
   
   For me the Pydantic thing comes as very similar thing - it should be 
"extension" that should be IMHO implemented outside of core. So maybe it's the 
right time to do this kind of refactoring -> Implement "discovery" mechanism in 
providers manager to discover which serializers are installed (similarly as all 
other extensions) - and similarly speciic "pydantic" model could be provided as 
"extension" - by a provider or manually.
   
   I'd love to hear thought about it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to