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 >
