[airflow] Fix ImportPathMoved / ProviderName misuse (AIR303)

[Lee-W]

Summary

• fix ImportPathMoved / ProviderName misuse
  • oncrete names, such as ["airflow", "config_templates", "default_celery", "DEFAULT_CELERY_CONFIG"], should use ProviderName. In contrast, module paths like "airflow", "operators", "weekday", ... should use ImportPathMoved. Misuse may lead to incorrect detection.

Test Plan

update test fixture

[Lee-W]

I'm thinking of splitting related test cases into separate files in the following PRs. Otherwise, it's a bit difficult to check the test cases.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+5 -5 violations, +0 -0 fixes in 1 projects; 54 projects unchanged)

apache/airflow (+5 -5 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --no-fix --output-format concise --preview --select ALL

- dev/perf/dags/perf_dag_1.py:41:10: AIR302 `airflow.operators.bash_operator.BashOperator` is removed in Airflow 3.0
+ dev/perf/dags/perf_dag_1.py:41:10: AIR303 Import path `airflow.operators.bash_operator` is moved into `standard` provider in Airflow 3.0;
- dev/perf/dags/perf_dag_1.py:48:12: AIR302 `airflow.operators.bash_operator.BashOperator` is removed in Airflow 3.0
+ dev/perf/dags/perf_dag_1.py:48:12: AIR303 Import path `airflow.operators.bash_operator` is moved into `standard` provider in Airflow 3.0;
- performance/src/performance_dags/performance_dag/performance_dag.py:95:13: AIR302 `airflow.operators.bash.BashOperator` is removed in Airflow 3.0
+ performance/src/performance_dags/performance_dag/performance_dag.py:95:13: AIR303 Import path `airflow.operators.bash` is moved into `standard` provider in Airflow 3.0;
- providers/edge/src/airflow/providers/edge/example_dags/integration_test.py:115:24: AIR302 `airflow.operators.bash.BashOperator` is removed in Airflow 3.0
+ providers/edge/src/airflow/providers/edge/example_dags/integration_test.py:115:24: AIR303 Import path `airflow.operators.bash` is moved into `standard` provider in Airflow 3.0;
- tests/decorators/test_bash.py:521:13: AIR302 `airflow.operators.bash.BashOperator` is removed in Airflow 3.0
+ tests/decorators/test_bash.py:521:13: AIR303 Import path `airflow.operators.bash` is moved into `standard` provider in Airflow 3.0;

Changes by rule (2 rules affected)

code	total	+ violation	- violation	+ fix	- fix
AIR303	5	5	0	0	0
AIR302	5	0	5	0	0

[dhruvmanila]

I'm thinking of splitting related test cases into separate files in the following PRs. Otherwise, it's a bit difficult to check the test cases.

I think that'd be useful. We usually prefer self-contained PRs as it's much easier to review. As per the PR description, it seems like this might be doing multiple things (Fix AIR303, refactor AIR302 and improve error message in AIR302). If it's not too much to ask, is it possible to split them in their own separate PRs? It'll also be useful for the CHANGELOG as the entries are generated using PR title. Let me know what you prefer, otherwise I can review the PR.

[Lee-W]

I'm thinking of splitting related test cases into separate files in the following PRs. Otherwise, it's a bit difficult to check the test cases.

I think that'd be useful. We usually prefer self-contained PRs as it's much easier to review. As per the PR description, it seems like this might be doing multiple things (Fix AIR303, refactor AIR302 and improve error message in AIR302). If it's not too much to ask, is it possible to split them in their own separate PRs? It'll also be useful for the CHANGELOG as the entries are generated using PR title. Let me know what you prefer, otherwise I can review the PR.

I love this idea! I was worried about creating too many small PRs. Thanks for letting me know!

[Lee-W]

I just splited this into 3 pull requests (including this one). 🙌 I may need to rebase a bit after one is merged, but I should be fine.

[dhruvmanila]

@Lee-W Is this ready to be reviewed? Is it rebased after the split PRs have been merged?

[Lee-W]

@Lee-W Is this ready to be reviewed? Is it rebased after the split PRs have been merged?

Hi, yes, this is already based on those PRs.

[dhruvmanila]

Looks good, minor one small question.