potiuk commented on issue #22248: URL: https://github.com/apache/airflow/issues/22248#issuecomment-1099065866
But is this a workable long term solution? Are we going to keep it this way in the future? We would have to change the documentation for custom providers and add it as explanation: "this is the way you should do it". And then when we split and possibly change the approach for both "community" and "3rd-party" proiders and change the way how custom connections are defined they will have to change again likely (And we will have to support - for compatibility): 1) provider.yaml 2) provider_info from entrypoint 3) metadata for the doc url 4) and the future way we will come up with (I think what we will likely end up in some sort of YAML with all the infor embedded as meta-data entry (maybe) ?? That includes explaining in the docs relation between 2) and 3) and having to explain the users that they have to combine both solutions for now - some information in provider_info entrypoint, some information in package metadata as separate, unrelated entry. And when we introduce 4) we will have to explain again the change (and for quite a while suport all 2) 3) 4) for compatibility for 3rd-party providers. Do we really want to add 3) now ? Or should we simply add another optional key in provider.yaml/info (especially that it already has all support for validating the schema, optional extending of the yaml (we've already added some extra stuff there) I'd say we should rather keep 1) 2) (with new key in yaml) and in the meantime figure out the way how we will do 4) when we work out how we get rid of the "customised code" in connections. -- 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]
