You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2020/11/19 11:12:07 UTC

[GitHub] [airflow] ashb commented on a change in pull request #12466: Adds support for Connection discovery from providers

ashb commented on a change in pull request #12466:
URL: https://github.com/apache/airflow/pull/12466#discussion_r526779883



##########
File path: airflow/provider.yaml.schema.json
##########
@@ -17,6 +17,11 @@
         "type": "string"
       }
     },
+    "provider-package": {

Review comment:
       >         are we allowing any package to contain provider?
   
   Yes, I firmly believe this should be the case. By not having third party packages live under the `airflow.` namespace, it becomes much much easier for Us and hopefully users to know what is an official provider, and thus supported by us vs not.
   
   I think the best approach would be something like a setuptools entrypoint.
   
   That way _any_ package can register a provider, by adding something like this to it's setup.cfg:
   
   ```ini
   [options.entry_points]
   apache-airflow-provider=
       x=my_company.provider.x:register_provider
   ```
   
   And then in `my_company/provider/x.py` we could have something like this:
   
   ```python
   def get_provider_info():
       return {
           description: "X"
       }
   ```
   
   We don't need to include the package name, nor the version, as those are available from Entrypoint already.
   
   In short: Python already has this mechanism that is well used. Let's not re-invent something different.




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org