And by removing them/making them dynamic the ide will think they don't even exist anymore.
(Also: these have been showing as deprecated in IDEs for ~2 years; If someone was going to update their code they would have already) On 5 August 2022 09:58:38 BST, Ash Berlin-Taylor <a...@apache.org> wrote: >I think the _goal_ is to not have the deprecated classes show up in IDEs - >i.e. we want to discourage people from using them. > >On 5 August 2022 09:44:42 BST, "Kamil Breguła" <dzaku...@gmail.com> wrote: >>I am concerned that the use of dynamic attributes will prevent the IDE from >>recognizing these deprecated modules and marking them in the IDE. >>This is what it looks like in my IDE now: https://imgur.com/a/OnRjiKs >> >>pt., 5 sie 2022 o 00:28 Ferruzzi, Dennis <ferru...@amazon.com.invalid> >>napisał(a): >> >>> > add dynamic attributes to __init__ of airflow.contrib, >>> airflow.operators, airflow.hooks. (to resolve to provider operators). >>> >>> This sounds promising to me. >>> >>> ------------------------------ >>> *From:* Jarek Potiuk <ja...@potiuk.com> >>> *Sent:* Thursday, August 4, 2022 6:52 AM >>> *To:* dev@airflow.apache.org >>> *Subject:* RE: [EXTERNAL][DISCUSS] Move "contrib" and all old classes to >>> a separate package >>> >>> >>> *CAUTION*: This email originated from outside of the organization. Do not >>> click links or open attachments unless you can confirm the sender and know >>> the content is safe. >>> >>> > This is the issue though. apache-airflow does not depend on >>> apache-airflow-providers-google >= 8.0, so you can still be on the same >>> version of the provider on 2.3 and 2.4, but by _only_ upgrading >>> apache-airflow package your DAG now breaks. >>> >>> Correct. The difference is that by only upgrading apache-airflow alone you >>> will break it. And I see why this might be seen as "problematic". >>> >>> But I have another idea. Why - rather than keeping the deprecations in the >>> code we load such deprecated we add dynamic attributes to __init__ of >>> airflow.contrib, airflow.operators, airflow.hooks. (to resolve to provider >>> operators). >>> >>> Such dynamic attributes will be invisible to autocompletion, will not be >>> documented with APIs nor visible in the source code (Except deep inspection >>> of __init__ in those packages). >>> >>> This has no compatibility breaking potential whatsoever >>> >>> >>> J. >>> >>> >>> On Thu, Aug 4, 2022 at 3:47 PM Ash Berlin-Taylor <a...@apache.org> wrote: >>> >>>> On Thu, Aug 4 2022 at 13:59:23 +02:00:00, Jarek Potiuk <ja...@potiuk.com> >>>> wrote: >>>> >>>> When you migrate to Airflow 2.4 and it links to the 8.0 version of Google >>>> provider (assume 2.3 linked to 7) you have to make changes to make it work >>>> in backwards incompatible way - you have to downgrade google provider to >>>> 7.0. You still can do it, but it is not "out-of-the-box". >>>> >>>> >>>> This is the issue though. apache-airflow does not depend on >>>> apache-airflow-providers-google >= 8.0, so you can still be on the same >>>> version of the provider on 2.3 and 2.4, but by _only_ upgrading >>>> apache-airflow package your DAG now breaks. >>>> >>>> >>>>
