Thanks Kamil for putting the document together. I wasn't able to respond earlier since I was giving Airflow workshops throughout Europe :-)
*Case 1: *Solution A → Remove everything from contrib into a single package. To make it easier to the end-user, my preference would be to get rid of the contrib package altogether. What's in contrib or not is a tricky question, I think this is already reflected in the document since "maturity" is in quotes. What would be the moment to transfer the operator to the core or vice versa? I'm afraid that renaming contrib to incubating will confuse the user even more. For people who aren't as known with Airflow it isn't that transparent which operator lives where, especially if you don't use an IDE such as Ash ;) Besides that I don't think it is worth changing the public API just for a different name. *Case 2:* Slight preference to Solution B (let's say a +0) I like to search on Github with t, and then search for BashOperator. After the change, you should search for Operator/Bash. Jarek, I'm confused with your vote on this, from your mail you state: - *Case 2: B: Airflow.operators.foo_operator.FooOperator could become airflow.operators.foo.FooOperator*. But the B solution is keeping it the same, so that would mean - *Case 2: B: Airflow.operators.foo_operator.FooOperator *would stay airflow.operators.foo_operator*.FooOperator* *Case 3:* I'm leaning towards B Mostly because it isn't as trivial to decide when it gets its own package or not. Besides the cloud providers, there are companies like Databricks and Qubole which might also end up with their own package because their integration is getting richer over time. Moving this is a bit painful because we need to deprecate the old path and move everything which introduces noise into version control etc. *C**ase 4: *B: No namespace introduction *Case 5: *B: Keep "Operator" (and "Sensor") suffixes on class names For the import is might look redundant, but for the UI I like to have it explicit. Also when you have Python code itself, I prefer DummyOperator( .. ) instead of Dummy( .. ). Let's quote the Python zen here: Explicit is better than implicit. *Case 6: *+1 Consistency is king. *Case 7:* Python native solution Jarek, what's your vote on this? --- Apart from all, great work! Cheers, Fokko Op di 23 jul. 2019 om 21:27 schreef Felix Uellendall <felue...@pm.me.invalid >: > I have no strong "No" against any proposed change of these cases. So I go > with +1 (non-binding). > > P.S. Thanks Jarek for bringing this up again and your intense work towards > airflow currently :) and thanks to Kamil for even creating this document. I > like how the code is getting more and more consistent and clean :) > > Kind regards, > Felix > > Sent from ProtonMail mobile > > -------- Original Message -------- > On Jul 23, 2019, 18:34, Jarek Potiuk wrote: > > > Hello everyone, > > > > This email is calling a vote on the changes in import paths. It's been > > discussed in > > > https://lists.apache.org/thread.html/4e648d9421c792d4537f5ac66f1a16dce468f816fc5221a9f9db9433@%3Cdev.airflow.apache.org%3E > > > > The vote will last for at least 1 week (July 30th 6pm CEST), and at least > > three +1 (binding) votes have been cast. > > > > The proposal to vote is based on the document from Kamil > > < > https://docs.google.com/document/d/1F8zve5S78DXcjpPttW89HnqT0M0iKjT6fo9jX57Ef6A/edit# > > > > > > The proposed solution is: > > > > - *Case 1: B: Contrib vs not: we move all that are "well" tested and > > rename contrib to "incubating" or similar.* > > - *Case 2: B: Airflow.operators.foo_operator.FooOperator could > > become airflow.operators.foo.FooOperator* > > - *Case 3: C: > > airflow.contrib.operators.gcp_bigtable_operator.BigTableOperator could > > become airflow.gcp.operators.bigtable.BigTableOperator* > > - *Case 4: B: no namespace introduction* > > - *Case 5: B: Keep "Operator" (and "Sensor") suffixes on class names* > > - *Case 6: We will treat isolated cases on case-by-case (and my team can > > do the job of GCP-related operators)* > > > > This is my (binding) +1 vote. > > > > Best regards, > > > > J. > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: [+48 660 796 129](tel:+48660796129) <[+48660796129](tel:+48660796129)> > > [image: Polidea] <https://www.polidea.com/>
