[airflow] passing positional argument into airflow.lineage.hook.HookLineageCollector.create_asset is not allowed (AIR301)

[Lee-W]

…e_asset has positional arguments

Summary

• passing positional argument into airflow.lineage.hook.HookLineageCollector.create_asset is not allowed
  • check whether positional argument with 0 index can be found

Test Plan

update the test fixture accordingly and reorganize in the next commit

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

I haven't followed the airflow PRs closely so I don't know if this is the first check for positional arguments.

Did airflow 2 allow position arguments but airflow 3 does no more?

I can see how this check is useful but it's something a type checker could catch too.

[MichaReiser]

Is this the intended message you want to show to users? Shouldn't it say instead that position arguments are disallowed?

[Lee-W]

Let me reword it again

[Lee-W]

After reading the whole message yet again, we should probably add a AIR303 for function signature change. I have another local branch working on something similar and moving this one there might be better as create_asset is not removed. Only its signature changed.

WDTY?

[MichaReiser]

Agree, AIR301 feels out of place for a signature change because it's not a removal

[Lee-W]

I haven't followed the airflow PRs closely so I don't know if this is the first check for positional arguments.

Yes, I think this is the first one

Did airflow 2 allow position arguments but airflow 3 does no more?

Yes.

I can see how this check is useful but it's something a type checker could catch too.

Yes, but we think it would still be helpful if these rules can also detect it here. As most of our users would be data engineers and might not care type checking that much

apache/airflow#47615 (comment)

[MichaReiser]

Yes, but we think it would still be helpful if these rules can also detect it here. As most of our users would be data engineers and might not care type checking that much

Fair enough. I'd prefer a separate rule because that would also make it easier to deprecate said rule when we introduce a general-purpose rule that detects positional arguments that should have been passed as keyword arguments (which we already have in ty)

[MichaReiser]

Thanks for working on this PR.

I'll close this PR as it seems stale. @Lee-W, don't hesitate to submit a new PR if you plan to get back to this.

[sjyangkevin]

thank you @Lee-W for working on this, and thank you @MichaReiser for sharing the feedback. I discussed with @Lee-W , and I would like to pick up the work for adding this rule. As I am new to ruff, so I am still reviewing the contribution guide, and would like to start by asking some basic questions.

Create a new code AIR303

I am wondering if I need to open an issue to discuss the creation of the code AIR303 before starting the implementation. Have we decided on the naming for the new rule (e.g., detect_positional_argument, ...)?

High-level thinking on implementation

From my high-level understanding, the new code could be added to the code.rs, and then I need to create a new file under crates/ruff_linter/src/rules/airflow/rules to implement the rule, and link it with the new code. I am looking into the code change in this PR and trying to understand the process (https://docs.astral.sh/ruff/contributing/#example-adding-a-new-lint-rule) to get a deeper understanding on the details.

ruff/crates/ruff_linter/src/codes.rs

Lines 1119 to 1124 in c7eea1f

	(Airflow, "001") => rules::airflow::rules::AirflowVariableNameTaskIdMismatch,
	(Airflow, "002") => rules::airflow::rules::AirflowDagNoScheduleArgument,
	(Airflow, "301") => rules::airflow::rules::Airflow3Removal,
	(Airflow, "302") => rules::airflow::rules::Airflow3MovedToProvider,
	(Airflow, "311") => rules::airflow::rules::Airflow3SuggestedUpdate,
	(Airflow, "312") => rules::airflow::rules::Airflow3SuggestedToMoveToProvider,

Thanks,

[Lee-W]

I am wondering if I need to open an issue to discuss the creation of the code AIR303 before starting the implementation.

I think we're good? given that I didn't create an issue for this one.

Have we decided on the naming for the new rule (e.g., detect_positional_argument, ...)?

function_signature_change or something similar might be better