Sounds good, thanks for considering that, Arpit. Thanks & Regards, Amogh Desai
On Wed, Mar 18, 2026 at 11:24 AM Arpit Rathore <[email protected]> wrote: > Hi Amogh, > > Thanks for the feedback. > > This makes sense and I am happy to adopt the postgres-style approach: > consolidate into the existing influxdb provider and use runtime detection > to dispatch between influxdb_client (2.x) and influxdb3-python (3.x). > > The main difference vs postgres is that the connection model itself > changes(org+bucket for 2.x vs database for 3.x) and the query language > changes entirely (Flux vs SQL), so some code separation is unavoidable. > But keeping it all under one provider with runtime detection is the right > call. > I am working on updating the PR to reflect this. > > Thanks, > Arpit > > > > Sent with Proton Mail secure email. > > On Wednesday, 18 March 2026 at 10:38 AM, Amogh Desai < > [email protected]> wrote: > > > Hello Arpit, > > > > Thanks for initiating this. > > > > I checked the PR briefly and the first qn that pops to my head is what > Elad > > also commented on the PR about using the existing provider itself (I > > understand > > the incompatibility that you have mentioned fwiw) > > > > For maintainability purposes, I still wonder if there is a way to use the > > existing > > provider itself. Like I think postgres provider is a decent example for > > this. It supports > > both psycopg2 AND psycopg3 via runtime detection: > > > https://github.com/apache/airflow/blob/f386dd99ceed54e86ff3f84ef91d4bb320b148a8/providers/postgres/src/airflow/providers/postgres/hooks/postgres.py#L40 > > > > This is not blocking but something worth evaluating before creating a new > > provider > > in my opinion. > > > > > > Thanks & Regards, > > Amogh Desai > > > > > > On Tue, Mar 17, 2026 at 6:26 PM Arpit Rathore < > [email protected]> > > wrote: > > > > > Hi Airflow community, > > > > > > I have been working on a new provider to support InfluxDB 3.x > > > (Core/Enterprise/Cloud Dedicated): > > > https://github.com/apache/airflow/pull/58929 > > > > > > InfluxDB 3.x uses a completely different Python client > (influxdb3-python), > > > SQL queries (vs Flux > > > in 2.x), and a different connection model (database instead of > > > org+bucket). There is no shared > > > code with the existing influxdb provider - these are distinct > integrations > > > targeting different > > > products. > > > > > > Per AIP-95, I am looking for: > > > > > > 1. A second steward - someone willing to co-maintain the provider > through > > > incubation > > > 2. A committer sponsor - a committer willing to guide the provider > through > > > the incubation process > > > > > > I am committed to being the primary steward. The implementation is > > > complete (hooks, operators, > > > tests, docs). The main remaining work is rebasing and aligning with the > > > latest CI/tooling setup. > > > > > > Would anyone be willing to step into either role? Happy to discuss > further > > > here or on Slack. > > > > > > Thanks,Arpit > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
