Also if we try to break the pattern, the ripple effect on our CI would be quite huge. Handling that exception is not going to be easy. So IMHO - either [redis] installs redis provider or we have no redis provider, and then redis can do whatever.
On Thu, Aug 14, 2025 at 7:52 PM Jarek Potiuk <ja...@potiuk.com> wrote: > Ah.. Yes. Sorry - thanks Jed - you are right. I mis-read it.. > > What my proposal would be is to keep redis to do what it does but have > optional `[redis]' (alongside ['rabbitmq'' on celery provider: > "apache-airflow-providers-celery[redis]` - and it would **not** install > redis but install redis as dependency. And also what we could add is a > combo "celery-redis" that would install > "apache-airflow-providers-celery[redis]". > > However - I would propose something else to keep the consistency. Why > don't we already rename redis provider to "keyval" or something else and > have it work for both redis and valkey ? Even if we do not want to > implement anything specific for "valkey". For me that would be quite a good > solution for now - no "two" providers separately - just one for now. > > THEN we could indeed change "redis" dependency to point to just redis > dependencies - as there will be no "redis" provider. > > J. > > > On Thu, Aug 14, 2025 at 7:24 PM Jed Cunningham <jedcunning...@apache.org> > wrote: > >> It feels like a slippery slope to depart from the "apache-airflow[x]" -> >> "apache-airflow-providers-x" pattern when x is a valid provider name. >> Right >> now it's easy to know what it'll do before you run, but if we did this >> you'd either have to look it up or try it. >> >
