Re: [PROPOSAL] Migrate to Pytest

+1 On Wed, Oct 30, 2019 at 5:37 PM Felix Uellendall wrote: > +1 of course 👍 > > Felix > > Sent from ProtonMail Mobile > > On Wed, Oct 30, 2019 at 17:31, Kaxil Naik wrote: > > > And yes we should merge it as soon as we have all green > > > > On Wed, Oct 30, 2019 at 4:28 PM Kaxil Naik wrote: > >

Re: [PROPOSE] Ease future migration path to 2.0 by provider's operators/hook backporting to 1.10.*

Let me run some tests too - I've used them a bit in the past. I thought since we only want to make airflow.providers a namespace package it might work for us. Will report back next week. -ash On 31 October 2019 15:58:22 GMT, Jarek Potiuk wrote: >The same repo (so mono-repo approach). All packa

Re: Managing external resources in Airflow

[ thanks Aizhamal for bumping up this thread ] Yes, since I posted originally, I was pointed at @jaketf's PR - https://github.com/apache/airflow/pull/6210 - and I have been active in the discussions there (I'm @JonnyIncognito) along with others. @Fokko is also helping wrt figuring out how to s

Re: [PROPOSE] Ease future migration path to 2.0 by provider's operators/hook backporting to 1.10.*

The same repo (so mono-repo approach). All packages would be in "airflow_integrations" directory. It's mainly about moving the operators/hooks/sensor files to different directory structure. It might be done pretty much without changing the current installation/development model: 1) We can add set

Re: [PROPOSE] Ease future migration path to 2.0 by provider's operators/hook backporting to 1.10.*

So create another package in a different repo? or the same repo with a separate setup.py file that has airflow has dependency? On Thu, Oct 31, 2019 at 2:32 PM Jarek Potiuk wrote: > TL;DR; I did some more testing on how namespaces work. I still believe the > only way to use namespaces is to ha

Re: [PROPOSE] Ease future migration path to 2.0 by provider's operators/hook backporting to 1.10.*

TL;DR; I did some more testing on how namespaces work. I still believe the only way to use namespaces is to have separate (for example "airflow_integrations") package for all backportable packages. I am not sue if someone used namespaces before, but after reading and trying out , the main blocker

Re: Inconsistent class names for AWS integrations

Good point. I often forget that Amazon do things other than AWS and selling things :) -a > On 31 Oct 2019, at 12:15, Kaxil Naik wrote: > > I think amazon/aws is better for 2 reasons: > > > - Consistent with what we are doing with google > - There can be API services for Amazon platform l

Re: Inconsistent class names for AWS integrations

I think amazon/aws is better for 2 reasons: - Consistent with what we are doing with google - There can be API services for Amazon platform like https://developer.amazon.com/apps-and-games/incentives-api | https://developer.amazon.com/docs/app-submission-api/overview.html etc On Thu

Re: Inconsistent class names for AWS integrations

Personally I would prefer not amazon. - it feels unnecessary as there's unlikely to be anything else but amazon.aws -a On 31 October 2019 09:29:18 GMT, MinJae Kwon wrote: >I love all those rules too :) > >On 2019/10/30 08:13:27, Bas Harenslak >wrote: >> Hi, >> >> How about the following conv

Re: Inconsistent class names for AWS integrations

I love all those rules too :) On 2019/10/30 08:13:27, Bas Harenslak wrote: > Hi, > > How about the following conventions? > > * No AWS in whatever notation in the class name, since this is already in > the module (airflow.providers.aws….) > * Only exception to above is the AwsHook, wh

Re: New promotional materials for Airflow

That's amazing Kamil, thanks for sharing this! Karolina Rosół Polidea | Project Manager M: +48 606 630 236 <+48606630236> E: karolina.ro...@polidea.com [image: Polidea] Check out our projects! [image: Github

Re: Managing external resources in Airflow

Hello, I wonder how much this PR is the solution to your problems. https://github.com/apache/airflow/pull/6210 This PR improves the use of resources when the operation is performed remotely. Best regards, On Thu, Oct 31, 2019 at 2:05 AM Aizhamal Nurmamat kyzy wrote: > > Is anyone able to give u

Re: Inconsistent class names for AWS integrations

Yep It is already part of AIP-21 but we left some details like decision how to split/structure internally particular provider further up to the person doing the split. However amazon/aws sounds like the best way to go I think. And backporting isn't (yet) as namespaces were originally proposed but