[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)