potiuk commented on code in PR #48849:
URL: https://github.com/apache/airflow/pull/48849#discussion_r2030923348
##########
providers/airbyte/src/airflow/providers/airbyte/get_provider_info.py:
##########
@@ -26,35 +26,6 @@ def get_provider_info():
"package-name": "apache-airflow-providers-airbyte",
"name": "Airbyte",
"description": "`Airbyte <https://airbyte.com/>`__\n",
- "state": "ready",
- "source-date-epoch": 1743477757,
- "versions": [
- "5.0.1",
- "5.0.0",
- "4.0.0",
- "3.9.0",
- "3.8.1",
- "3.8.0",
- "3.7.0",
- "3.6.0",
- "3.5.1",
- "3.5.0",
- "3.4.0",
- "3.3.2",
- "3.3.1",
- "3.3.0",
- "3.2.1",
- "3.2.0",
- "3.1.0",
- "3.0.0",
- "2.1.4",
- "2.1.3",
- "2.1.2",
- "2.1.1",
- "2.1.0",
- "2.0.0",
- "1.0.0",
- ],
"integrations": [
Review Comment:
I thought about it, but I think it's best to leave them for compatibility
(but also they add a value potentially for anyone who wants to do **more** with
providers - for example it allows to see easily which hooks and operators and
sensor the provider has rather than walking through provider classes. We are
already doing that in pre-commits - walking through provider classes and
discovering those in pre-commit that verifies provider.yaml consistency with
the code, so capturing it in get_provider_info makes sense and does not require
extra effort.
Some of them (not all) were mentioned in the docs as way of communicating
what the provider supports -while we do not use them at runtime, this is the
only way users could potentially disover (if they want to use it) what feature
our (and custom providers) expose. Many of those (not all - I am making sure
things are synchronized) have been described in the docs and in the schema
which is part of the docs ->
https://airflow.apache.org/docs/apache-airflow-providers/howto/create-custom-providers.html#how-to-create-a-provider
Changing those (other than removing the accidentally added
dependencies/versions etc.) would be somewhat breaking because there is no
other way to discover those features easily (unless with dependencies and
optional-dependencies where you can use "importlib.metadata" - so we can
provide a replacement).
So I'd rather leave them, and also I left TODO for later in the coming weeks
to automate the documentation - all the documentation can be derived from
`provider_info` schema automatically and verified if all that is consistent.
I am just updating the docs in "custom providers" to add those missing ones
and remove from get_provider_info those that have never been mentioned in the
docs, nor schema and updating provider docs with that.
--
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]
