My preference: Case 1: (contrib vs not) A (move all) or B (move all that are "well" tested).
Case 2 irflow.operators.foo_operator.FooOperator could become A: airflow.operators.foo.FooOperator Case 3: airflow.contrib.operators.gcp_bigtable_operator.BigTableOperator could become A: airflow.contrib.operators.gcp.bigtable.BigTableOperator or C: airflow.gcp.operators.bigtable.BigTableOperator Case 4: (separate packages/namesapces) B: no namespaces for now is my vote. Case 5: "Operator" suffix on class names Leaning towards B (keep) as some operators don't make sense without it (PythonOperator, being the prime example). We'd probably have to keep the Sensor suffix so Operator makes it more "even". -ash > On 18 Apr 2019, at 15:13, Ash Berlin-Taylor <[email protected]> wrote: > > This has some overlap with the "Deprecate contrib folder" right? > > -ash >> On 18 Apr 2019, at 14:57, Kamil Breguła <[email protected]> wrote: >> >> Hello all, >> >> During the 4-year project development, the community made many >> decisions about the structure and principles of module creation. Some >> decisions have been made by Airbnb and they no longer apply. Other >> recommendations were rejected because of the low recognition of the >> community. >> >> I have created a document that collects several issues related to >> import paths, because I see that this appears in the discussion many >> times. >> https://docs.google.com/document/d/1F8zve5S78DXcjpPttW89HnqT0M0iKjT6fo9jX57Ef6A/edit# >> However, it is not possible to solve this problem at the level of >> individual contributions, but it is necessary to organize at the >> project level >> >> I invite everyone to discuss the topic presented in this document. >> >> Greetings, >> >> -- >> Kamil Breguła >> Polidea | Software Engineer >> >> M: +48 505 458 451 >> E: [email protected] >> >> We create human & business stories through technology. >> Check out our projects! >
