Agree with Kaxil. I've seen the message from Trinodb and I believe we should really care about them. If the new 'Facebook' Presto would like to have their provider, they can contribute it as "prestodb", but we should not try to support both without their commitment to maintain it :).
J. On Thu, Jan 21, 2021 at 1:02 AM Kaxil Naik <kaxiln...@gmail.com> wrote: > I like (2) but without adding a new 'apache-airflow-providers-prestodb' > for Facebook's prestodb -- especially since I don't currently know if the > python client library will continue to work with it unless someone tests > and adds it. > > > > On Wed, Jan 20, 2021 at 11:43 PM Philippe Gagnon <philgagn...@gmail.com> > wrote: > >> Hello Airflow-dev, >> >> About a couple of years ago the Presto community was fractured when the >> three founders of the project, Dain, David and Martin, left Facebook due to >> irreconcilable differences with the company concerning the stewardship of >> the open-source project. In order to continue working on the open-source >> Presto software, they founded the Presto Software Foundation and forked the >> prestodb project on GitHub, renaming it to prestosql. Most active >> contributors followed them and started directing their PRs towards the >> prestosql repository, which has thrived since then, overtaking the prestodb >> project as the most active "Presto" flavor. >> >> Nevertheless, the community around the original Facebook prestodb project >> was diminished but carried on with their work. Over time incompatibilities >> started to appear between the two products which no longer shared a common >> vision and roadmap. Eventually Facebook leadership decided to formalize the >> community around their version of Presto by creating another Presto >> Foundation under the auspices of the Linux Foundation. The Presto >> Foundation then filed a trademark for the Presto name, forcing the >> prestosql project to change their name to trinodb late last year [1]. >> >> This puts us here in the Airflow community in a bit of a conundrum. I >> believe that over the past two years or so we have primarily targeted >> support for the prestosql version of Presto (which has now been renamed). >> With that in mind we should probably rename >> our apache-airflow-providers-presto package >> to apache-airflow-providers-trino. However, this is a backwards >> incompatible move and risks causing a high level of confusion among our >> users as there is still the prestodb project which is more or less >> wire-compatible with trinodb, and there is merit to supporting both. >> >> I'm not sure what the best path forward is on our side as every option I >> can think of has pros and cons, as such I think it warrants a discussion >> with the dev community. >> >> Off the top of my head: >> >> 1. We create apache-airflow-providers-trino and start using >> apache-airflow-providers-presto for prestodb. This has the disadvantage of >> possibly introducing incompatibilities down the line for users of >> prestosql/trinodb who fail to update to the new provider. >> 2. We create apache-airflow-providers-trino and alias >> apache-airflow-providers-presto so that it points to the modules in >> apache-airflow-providers-trino while providing a deprecation warning. We >> also create an apache-airflow-providers-prestodb provider package for >> users >> of Facebook's prestodb. Eventually in a subsequent release we >> remove apache-airflow-providers-presto altogether. This is less disruptive >> for users, but can also be confusing if we don't get our messaging right. >> >> Best, >> >> Philippe >> >> [1] https://trino.io/blog/2020/12/27/announcing-trino.html >> > -- +48 660 796 129
