[DISCUSS] Move all airflow infra hooks from settings.py to its own file

Hi all, Currently, those infra hooks (e.g. task_policy, dag_policy etc) live in the settings.py, making it bloated. I am proposing to move those infra hooks to its own file. As for the

Re: [DISCUSS] Trimming down Airlfow Versions in issues

So far we've been talking about Airflow core bugs, but we do have 2 other issue templates that ask for the Airflow version - chart and providers. Both of those ultimately do support non-latest core versions, so I don't think we can be quite as blunt there. We either keep the full list or convert

Re: [DISCUSS] consolidate dag scheduling params

Fair points all. I withdraw my objection and agree with the consolidation proposal. Vikram On Fri, Aug 5, 2022 at 10:06 AM Jarek Potiuk wrote: > Let me also add to why I think we should consolidate to one param:: > > * "schedule_interval" > * "schedule_on" > * "timetable" > > Imagine you are

Re: [DISCUSS] consolidate dag scheduling params

Let me also add to why I think we should consolidate to one param:: * "schedule_interval" * "schedule_on" * "timetable" Imagine you are a new user coming to Airflow. Do you immediately recognise which one is which ? Do you see what the difference is? * "Schedule_on" = "Every Sunday" is equally

Re: [DISCUSS] consolidate dag scheduling params

@Vikram, yeah, I understand that concern. Making a breaking change is something we shouldn't do carelessly, without consideration, without good reason. But I think we have a good reason here. Deprecations are somewhat regular in airflow. In 2.0 we moved a lot of imports. We also changed the

Re: [DISCUSS] Move "contrib" and all old classes to a separate package

https://lists.apache.org/thread/cp9n8r9x75xzzsdjgdqd82p8nmyn1nd5 -> non-broken link here. On Fri, Aug 5, 2022 at 1:15 PM Jarek Potiuk wrote: > And I agree with Ash - two years ago it would be a bad choice but we are > past the time when we should be "gentle" with it :). > > But we are now at

Re: [DISCUSS] Move "contrib" and all old classes to a separate package

Yeah. Removing them from IDE is PRECISELY the goal :). On Fri, Aug 5, 2022 at 11:01 AM Ash Berlin-Taylor wrote: > 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

Re: [Discuss] AIP-44 Airflow Database API

This is a very good question. What actually makes it a bit easier to reason about it, is that in all our cases a single RPC method call spans a single transaction (this is the boundary of the RPC methods we have and the main decision point on whether to split it or not). There are few error

Re: [DISCUSS] Move "contrib" and all old classes to a separate package

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 wrote: >I think the

Re: [DISCUSS] Move "contrib" and all old classes to a separate package

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" wrote: >I am concerned that the use of dynamic attributes will prevent the IDE from >recognizing these deprecated modules

Re: [DISCUSS] Move "contrib" and all old classes to a separate package

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 napisał(a): > > add dynamic attributes to