升级Airflow2.0.1/Python3.9后自定义Python宏导入失败问题排查

这个导入失败的核心原因是Airflow 2.0 彻底移除了1.x版本针对插件宏的兼容导入路径支持，具体逻辑如下：

• Airflow插件机制里定义的macros配置项，原生设计用途是将函数对象自动注入到DAG渲染Jinja模板的全局命名空间，供{{ macros.xxx() }}这类模板语法调用，从设计之初就不是为了把函数注册成可通过Python语法导入的模块路径。
• 你在Airflow 1.10.5版本中能通过from airflow.macros.ben import ret_one正常导入，是因为1.x版本专门加了一段兼容逻辑：把所有插件注册的宏动态挂载到airflow.macros模块路径下，方便老版本用户导入。Airflow 2.0出于架构清理，完全删除了这段动态挂载逻辑，所以即便你在UI的插件页面能正常看到已加载的ret_one插件，系统也永远不会在airflow.macros路径下生成对应的可导入模块，自然抛出ModuleNotFoundError。
• 你尝试其他变体导入写法也无法成功，是因为插件注册的宏仅以函数对象的形式存储在Airflow运行时的内存字典里，不会在文件系统的airflow/macros/目录下生成对应的实体Python文件，根本不存在可导入的模块路径。

根据你的实际使用需求选择适配方案即可：

• 如果仅需要在DAG的Jinja模板中使用该函数
  不需要额外加任何Python导入语句，直接在模板字符串中调用即可。由于你的插件已经通过macros = [ret_one]完成了函数注册，Airflow会自动将函数挂载到Jinja的macros对象下，调用写法为{{ macros.ret_one() }}。
• 如果需要在DAG的Python代码中直接调用ret_one作为普通工具函数
  无需绕路依赖Airflow的内置模块路径导入，直接利用Airflow启动时自动将plugins目录加入Python搜索路径的机制，写为from ben import ret_one即可正常导入。

注意：不要为了强行适配老的导入写法，在airflow/macros/目录下手动创建文件链接或者自定义重写导入逻辑，这会破坏Airflow 2.0的插件隔离架构，后续升级版本时会出现未知兼容问题。

内容的提问来源于stack exchange，提问作者Ben Watson