Move BaseOperatorLink into the separate module

[Taragolis]

Move BaseOperatorLink from airflow.models.baseoperator into the separate module this might slightly reduce import in case of creation extra.

In additional remove check-base-operator-usage pre-commit checks which are prevents direct use of airflow.models.baseoperator.BaseOperatorLink and forced contributors to use airflow.models.BaseOperatorLink in providers and other parts

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

The new packages should be added here: https://airflow.apache.org/docs/apache-airflow/stable/public-airflow-interface.html

Also - are we going to update the providers with importing the new one ? Otherwise all operators will raise deprecation warning ?

[Taragolis]

Community providers should not raise warnings, because all of them use lazy import from airflow.models

[potiuk]

LGTM. @uranusjr ?

[potiuk]

Community providers should not raise warnings, because all of them use lazy import from airflow.models

Right. Then we don't even have to do the try/Except. BUT that made me think. Maybe this calls for NOT removing the provider pre-commit @Taragolis ? There is a reason why it is like that and if we remove the pre-commit, then providers MIGHT start diverging where they are importing it from.

WDYT?

[Taragolis]

Then we don't even have to do the try/Except.

Try/except might required only if #34600 completed. Some ideas why it might be a good idea (or maybe not)

• Import Dataset from airflow.datasets to avoid circular dependency #34586 (comment)
• Ban import AirflowException from airflow #34512 (comment)

There is a reason why it is like that and if we remove the pre-commit, then providers MIGHT start diverging where they are importing it from.

We could ban airflow.models.baseoperator.BaseOperatorLink in airflow codebase by the same way as we ban
from airflow import AirflowException and from airflow import AirflowException

airflow/pyproject.toml

Lines 151 to 153 in 303a329

	[tool.ruff.flake8-tidy-imports.banned-api]
	"airflow.AirflowException".msg = "Use airflow.exceptions.AirflowException instead."
	"airflow.Dataset".msg = "Use airflow.datasets.Dataset instead."

[potiuk]

We could ban airflow.models.baseoperator.BaseOperatorLink in airflow codebase by the same way as we ban
from airflow import AirflowException and from airflow import AirflowException

Yep. We could. That would work.

[uranusjr]

I’m not sure if this should be removed outright. Instead we may want to check the two classes are imported from respectively correct modules.

[Taragolis]

Just for clarify which behavior we expect here

Option 1:
Outside of core airflow.models.baseoperator.BaseOperator and airflow.models.baseoperatorlink.BaseOperatorLink should be imported from airflow.models

Option 2:
Allow to use airflow.models.baseoperator.BaseOperator and airflow.models.baseoperatorlink.BaseOperatorLink
Ban import airflow.models.baseoperator.BaseOperatorLink

[uranusjr]

In core: Allow only airflow.models.baseoperator.BaseOperator and airflow.models.baseoperatorlink.BaseOperatorLink

Outside core: Allow only airflow.models.BaseOperator and airflow.models.BaseOperatorLink

[potiuk]

yeah.

[ferruzzi]

@uranusjr - Are you good with this one getting merged?

[eladkal]

static checks are failing

[ferruzzi]

It's all green and Jarek has approved. No reply from Tzu-ping in a few weeks but it does appear to me that his concerns were addressed. I think we can merge it??

[Taragolis]

Let's rebase first and have a look is is still working