Hi David, Thanks for raising this discussion. following the protocol established about accepting new providers - https://github.com/apache/airflow/blob/main/PROVIDERS.rst#accepting-new-community-providers My main concern here is how will provide ongoing mantaince for this provider? This provider is to handle a service by Microsoft yet Microsoft is not in the picture here (as far as I can see)
On Sat, Jan 13, 2024 at 12:39 PM Blain David <david.bl...@infrabel.be> wrote: > Hello everyone, > > I've already started a discussion about this on the Airflow discussions: > https://github.com/apache/airflow/discussions/36315 > > As we have multiple DAG's interacting with MS Graph API endpoints, and as > we want to avoid custom code as much as possible as we have to handle lot's > of data due to paging. > We thought of implementing an operator for it using the official python > client from Microsoft<https://github.com/microsoftgraph/msgraph-sdk-python>, > that way we can simplify our DAGs and remove custom code as much as > possible. > That's why we implemented an MSGraph SDK Provider which is on GitHub< > https://github.com/infrabel/apache-airflow-providers-msgraph> and also > published it as an artifact on PyPi< > https://pypi.org/project/apache-airflow-providers-msgraph/>. > > As Jarek pointed out in the pull request for Third Party providers< > https://github.com/apache/airflow-site/pull/933>, it's not a good idea to > use the apache-airflow prefix for the library as it is not maintained by > the Apache community (yet). > So there are 2 options, or we change the name or we donate the project to > the Apache Airflow community, which I think the later one is the best > option if there is interest to do it, hence why I also started a discussion< > https://github.com/apache/airflow/discussions/36315> about it a few weeks > ago on GitHub<https://github.com/apache/airflow/discussions/36315>. > > Kind regards, > David > >
