An example where deprection_tools are still used
https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/utils/log/__init__.py
It's rather straightforward = needs a package with __init__.py - only where
you list all the classes and provide redirections. It will
automatically raise deprecation warnings:
from airflow.utils.deprecation_tools import add_deprecated_classes
__deprecated_classes = {
"cloudwatch_task_handler": {
"CloudwatchTaskHandler": (
"airflow.providers.amazon.aws.log.cloudwatch_task_handler.CloudwatchTaskHandler"
),
},
"es_task_handler": {
"ElasticsearchTaskHandler": (
"airflow.providers.elasticsearch.log.es_task_handler.ElasticsearchTaskHandler"
),
},
"gcs_task_handler": {
"GCSTaskHandler":
"airflow.providers.google.cloud.log.gcs_task_handler.GCSTaskHandler",
},
"s3_task_handler": {
"S3TaskHandler":
"airflow.providers.amazon.aws.log.s3_task_handler.S3TaskHandler",
},
"stackdriver_task_handler": {
"StackdriverTaskHandler": (
"airflow.providers.google.cloud.log.stackdriver_task_handler.StackdriverTaskHandler"
),
},
"wasb_task_handler": {
"WasbTaskHandler":
"airflow.providers.microsoft.azure.log.wasb_task_handler.WasbTaskHandler",
},
}
add_deprecated_classes(__deprecated_classes, __name__)
On Tue, Apr 1, 2025 at 1:49 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> We were going to have compatibility shims to redirect the imports - with -
> there are few ways to do it - Ash had a little POC with module loader, but
> I think it has some potential side effect and I think Ash abandoned
> the idea and I would personally prefer to use our old PEP-563 mechanism
> using airflow-core/src/airflow/utils/deprecation_tools.py,
>
> Very nice and small PR to implement if you want to contribute - and since
> you are testing it now with some existing DAGS it might also be a good test
> if no redirect has been forgotten
>
> J.
>
>
> On Tue, Apr 1, 2025 at 1:32 PM Eugen Kosteev <eu...@kosteev.com> wrote:
>
>> Hi everyone.
>>
>> I am testing compatibility of Airflow 2 DAGs with Airflow 3, and would
>> like
>> to discuss this topic.
>>
>> I took bunch of DAGs from existing Airflow 2 instances and deployed them
>> to
>> instance with Airflow 3 (3.0.0b4) and have bunch of import errors:
>> - ModuleNotFoundError: No module named
>> 'airflow.operators.python_operator'
>> - ModuleNotFoundError: No module named 'airflow.operators.bash_operator'
>> - ImportError: cannot import name 'email_operator' from
>> 'airflow.operators'
>> - ModuleNotFoundError: No module named
>> 'airflow.operators.dummy_operator'
>>
>> I know that users are supposed to migrate from using "airflow.operators"
>> to
>> standard/stmp/.. provider packages before upgrading to Airflow 3.
>>
>> But I also remember some discussions around keeping old imports work, by
>> rerouting them to the correct module (similarly as we do in case of
>> deprecated classes, etc.).
>> So, it will be very smooth for users to migrate to Airflow 3.
>>
>> What is our stand on this? Do we abandon "airflow.operators" usage in DAGs
>> in Airflow 3 completely?
>> Or this is something that needs to be done in Airflow 3, but not yet.
>>
>> --
>> Eugene
>>
>
