I love those all 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
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
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
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
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
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
+1 Isn’t that already covered by AIP-21?
Only what Jarek mentioned regarding the backporting to 1.10 isn’t I think.
I would go for “providers/amazon/aws” as well just to be consistent.
Felix
Sent from ProtonMail Mobile
On Wed, Oct 30, 2019 at 10:05, Jarek Potiuk wrote:
> Few comments:
>
> -
Few comments:
- I like the rules
- For google we add additional "google/gcp" , "google/gsuite".
"google/marketing_platform" packages in "providers". I am not sure if
Amazon will ever have something outside of AWS to interact with (but I can
imagine this might happen) so maybe from t
+1 to all of those conventions. And although that is a lot of classes in
airflow/providers/aws/operators/s3.py I like it that way rather than split out.
The only odd on is obviously `lambda_` but we have to do something to that.
-ash
> On 30 Oct 2019, at 08:13, Bas Harenslak wrote:
>
> Hi,
>
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, which is a “base” hook which most
other hooks inherit from
* No “Transfer” in class names
I think it's a great idea and I am willing to help.
Bests,
Tomek
On Wed, Oct 30, 2019 at 3:17 AM MinJae Kwon wrote:
> Hi all.
>
> While I was working on AIRFLOW-5803, I found there are inconsistencies
> between class names for each AWS operators/hooks.
>
> For example, Athena hook is named as '
Hi all.
While I was working on AIRFLOW-5803, I found there are inconsistencies between
class names for each AWS operators/hooks.
For example, Athena hook is named as 'AWSAthenaHook', but Dynamodb hook is
named as 'AwsDynamoDBHook', and S3 hook is just 'S3Hook' (So, AIRFLOW-5803 is
trying to re
12 matches
Mail list logo
