Repository: apache/airflow

Issue:
from airflow.operators.python import PythonOperator does not work
This is not necessarily a bug in core Airflow, but the upgrade-check scripts recommend this as a solution when the old 1.10.x version of importing the python operator is used. 

So, there is a mismatch between the core Airflow code and the recommendations given in the upgrade check. 

<!--

Welcome to Apache Airflow!  For a smooth issue process, try to answer the following questions.
Don't worry if they're not all applicable; just try to include what you can :-)

If you need to include code snippets or logs, please put them in fenced code
blocks.  If they're super-long, please use the details tag like
<details><summary>super-long log</summary> lots of stuff </details>

Please delete these comment blocks before submitting the issue.

-->

<!--

IMPORTANT!!!

PLEASE CHECK "SIMILAR TO X EXISTING ISSUES" OPTION IF VISIBLE
NEXT TO "SUBMIT NEW ISSUE" BUTTON!!!

PLEASE CHECK IF THIS ISSUE HAS BEEN REPORTED PREVIOUSLY USING SEARCH!!!

Please complete the next sections or the issue will be closed.
These questions are the first thing we need to know to understand the context.

-->

**Apache Airflow version**:


**Kubernetes version (if you are using kubernetes)** (use `kubectl version`):

**Environment**:

- **Cloud provider or hardware configuration**:
- **OS** (e.g. from /etc/os-release):
- **Kernel** (e.g. `uname -a`):
- **Install tools**:
- **Others**:

**What happened**:

<!-- (please include exact error messages if you can) -->

**What you expected to happen**:

<!-- What do you think went wrong? -->

**How to reproduce it**:
<!---

As minimally and precisely as possible. Keep in mind we do not have access to your cluster or dags.

If you are using kubernetes, please attempt to recreate the issue using minikube or kind.

## Install minikube/kind

- Minikube https://minikube.sigs.k8s.io/docs/start/
- Kind https://kind.sigs.k8s.io/docs/user/quick-start/

If this is a UI bug, please provide a screenshot of the bug or a link to a youtube video of the bug in action

You can include images using the .md style of
![alt text](http://url/to/img.png)

To record a screencast, mac users can use QuickTime and then create an unlisted youtube video with the resulting .mov file.

--->


**Anything else we need to know**:

<!--

How often does this problem occur? Once? Every time etc?

Any relevant logs to include? Put them here in side a detail tag:
<details><summary>x.log</summary> lots of stuff </details>

-->



Discussion:
This is the change that users need to make just before updating to 2.0 -- because this won't work with any 1.10.x versions
Perhaps this needs to be suggested as `try ... except ImportError` approach.
DummyOperator falls in to this same boat.
@ashb @kaxil I'm not sure what the issue is since the tradition `from airflow.operators.python_operator` works in 2.0.

This can be fixed post-upgrade.
@dimberman Well to start with: the upgrade check command suggests making a change that will break in 1.10.14.

Secondly people will forget after upgrading ;) 
@ashb sure we can make it a soft warning but after 2.0 they should get deprecation warnings (@ryanahamilton would be great if we could add UI elements that warn people if a DAG uses deprecated features though don't know if it's too close to release at this point)
Kamil has already started working on collecting other classes of DAG warnings for display in the UI -- he's got a WIP PR somewhere.
But anyway -- the issue is the upgrade check is suggesting something that would break users dags on 1.10.14, so that check will need updating.
In my dags I used this form: `from airflow.operators.python_operator import PythonOperator` which worked in both 1.10 + 2.0, so maybe a decent % of airflow users wouldn't be affected by this
> In my dags I used this form: `from airflow.operators.python_operator import PythonOperator` which worked in both 1.10 + 2.0, so maybe a decent % of airflow users wouldn't be affected by this

Yup it will work but will raise a deprecation warning in 2.0
Using old path will raise a warning. I think that current suggestion given by airflow upgrade check should be understood as "if you want to make your DAG fully compatible with Airflow 2.0 and limit number of warnings you get change the import path A to import path B". 

I can be wrong, be the check was to help migrate DAGs not to make them 1.10 and 2.0 compatible. Otherwise we have to redesign the checks. If we think that current behaviour  is unclear then we should improve either messages or docs (or both).
@turbaszek  It seems to me that we should try to ensure compatibility with Airflow 1.10 and Airflow 2.0 to be possible step by step. We've specially released backport packages to make this possible. Now users can test each integration one by one. Core operators are a different case, as they cannot be installed as a pip package. For this reason, it seems that some minor changes may still be needed.

Earlier thread that covered this topic.
https://github.com/apache/airflow/issues/11178#issuecomment-731043815

I've been working on displaying the warnings in the IU and it's almost done. I can do it tonight.
https://github.com/apache/airflow/pull/11960
Yeah -- with the exception of the core operators all the other changes suggested by upgrade-check will work on 1.10.14 and 2.0.0 -- for instance see https://github.com/apache/airflow/pull/12930 where we suggest (1.10.14 -> upgrade check -> fix warnings -> 2.0.0) so we'll need to make it very clear which ones can be done on 1.10.14 and which can't.
> Yeah -- with the exception of the core operators all the other changes suggested by upgrade-check will work on 1.10.14 and 2.0.0 -- for instance see #12930 where we suggest (1.10.14 -> upgrade check -> fix warnings -> 2.0.0) so we'll need to make it very clear which ones can be done on 1.10.14 and which can't.

Or maybe RC5 with those operators added to 1.10.14 ?
I'd rather a 1.10.15 if we wanted to do that -- lets get 1.10.14 out already!
Oh yeah!

Resolving patch:
diff --git a/airflow/upgrade/rules/import_changes.py b/airflow/upgrade/rules/import_changes.py
--- a/airflow/upgrade/rules/import_changes.py
+++ b/airflow/upgrade/rules/import_changes.py
@@ -39,7 +39,9 @@ class ImportChange(
     )
 ):
     def info(self, file_path=None):
-        msg = "Using `{}` should be replaced by `{}`".format(self.old_path, self.new_path)
+        msg = "Using `{}` should be replaced by `{}`".format(
+            self.old_path, self.new_path
+        )
         if file_path:
             msg += ". Affected file: {}".format(file_path)
         return msg
@@ -80,10 +82,30 @@ class ImportChangesRule(BaseRule):
         "https://github.com/apache/airflow#backport-packages"
     )
 
+    current_airflow_version = Version(__import__("airflow").__version__)
+
+    if current_airflow_version < Version("2.0.0"):
+
+        def _filter_incompatible_renames(arg):
+            new_path = arg[1]
+            return (
+                not new_path.startswith("airflow.operators")
+                and not new_path.startswith("airflow.sensors")
+                and not new_path.startswith("airflow.hooks")
+            )
+
+    else:
+        # Everything allowed on 2.0.0+
+        def _filter_incompatible_renames(arg):
+            return True
+
     ALL_CHANGES = [
-        ImportChange.from_new_old_paths(*args) for args in ALL
+        ImportChange.from_new_old_paths(*args)
+        for args in filter(_filter_incompatible_renames, ALL)
     ]  # type: List[ImportChange]
 
+    del _filter_incompatible_renames
+
     @staticmethod
     def _check_file(file_path):
         problems = []


Test patch: