potiuk commented on PR #41798: URL: https://github.com/apache/airflow/pull/41798#issuecomment-2314706054
Yes. Just remove the special testa (no Pydantic in main (and relevant code in entrypoint_ci.sh). I think we already know that Pydantic in Airflow 3 is a must with fastapi. When it comes to V2 vs. V1 - I'd be for removing V1 support as well. It still 6 months or so until Airflow 3 is out which will be already almost 2 years of Pydantic V2. All our community providers that need Pydantic already support V2. There are already few dependencies that only work with Pydantic 2 (pyiceberg weaviate-client) and we can expect more dropping it. The only problem is when someone uses their own libraries/old versions that support only V2. It's been a problem in the past - but we can expect it to be negligible. Also Airflow 3 is a bit delifferrnt beast altogether - when we do task-sdk separation and different set of dependencies (no providers) for scheduler/webserver and workers/processor/triggerer (with providers) the problem will be gone entirely - because Pydantic V2 will only be necessary for webserver. If (as I advocate for) we find a way to not have to install providers in webserver/API server - the problem will be gone entirely - this is yet another reason why I think we should aim for webserver not having to install providers in webserver for base operator links/ connections /log handlers - this way it will not matter if any custom code or providers has conflicting dependencies with webserver or not and we could make such decision without even blinking. -- 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]
