potiuk edited a comment on pull request #17625: URL: https://github.com/apache/airflow/pull/17625#issuecomment-899624391
What do you think - others? I think this is really, really useful to be able to see what kind of secret backends we have extra, what logging handlers, what authentication APIS we have. While I agree listing all operators/hooks/sensor for provider makes no sense, listing the "core feature extensions" of Airflow IMHO is worth to be queryable at runtime (and verifiable). For me this is again - disciverability problem (same as with docs) rather that "let the users figure it out and search on their own". There is big difference IMHO when you want to just integrate operators/sensors/hooks of a given service, comparing to when you want to extend a "built-in" airflow capability with a given integration. Those are even useful for different kind of users - logging/auth/seceret backends are for Devops/Operations people, where Operators/Hooks/Sensors are for Dag writers. Those are different audiences - CLI is there for the Devops, they will use to to query for different kinds of things and I find it would be super-useful. I believe we should not look at it from the "airflow developer" point of view where we treat Operators/Hooks/Sensors vs. Auth/Secrets/Logging as similar "beings" inside "provider" package (python constructs) and literally "the same kind of thing". But I think we should look at it from the side of the user - IMHO even if "Operators/Hooks/Sensors vs Auth/Secrets/Logging" are packaged together in a provider, they have conceptually completely different scope, they are used differently and they have different audience (and we should treat them differently), -- 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]
