mik-laj edited a comment on pull request #17625: URL: https://github.com/apache/airflow/pull/17625#issuecomment-899113732
I am not sure if I understand what we want to achieve in this change and if we really have adopted the correct data structure for what we want to achieve. Previously, adding new information to [`provider_info`](https://raw.githubusercontent.com/apache/airflow/e09ce9a25972344eb8760ccabea2ff042ed8ee35/airflow/provider_info.schema.json)/ProviderManager was always related to adding new features or as required by making existing features work. I considered the ability to view information using the CLI as features that only facilitated troubleshooting, but was never the main goal. Currently, we have the following keys in `providers_info.schema.json` on the main branch. `description` -> Makes it easier to identify the package. `extra-links` -> Required by extra links to prevent loading unknown classes. Only registered classes can create extra links. `hook-class-names` -> Required by Connection UI. `name` -> Makes it easier to identify the package. `package-name` -> Makes it easier to identify the package. Could you please give **the main purpose** why we want to add this information to provider_info? Should we also add information about operators, sensors, hooks to `provider_info`? How is Airflow going to behave when the class is not added to provider_info but is used by Airflow? If your main goal is to prepare a list of auth_backend/secrets-backend/task-handlers in our documentation. I think it is enough for us to just add these keys to `provider.yaml` like `operators`, `hooks`, `sensors`, `integrations`, without adding to `provider_info`. -- 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]
