Move decorators to standard provider

[romsharon98]

related: #43641

---

^ 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.

[uranusjr]

I don’t think we are moving core Airflow concepts like BaseOperator into the provider? Unless we are, at least @task should stay in core. Likely @setup and @teardown as well (since as_setup() and as_teardown() are on BaseOperator).

[romsharon98]

I don’t think we are moving core Airflow concepts like BaseOperator into the provider? Unless we are, at least @task should stay in core. Likely @setup and @teardown as well (since as_setup() and as_teardown() are on BaseOperator).

But isn't @ task mean PythonOperator and therefore we want it out of Core?

[potiuk]

But isn't @ task mean PythonOperator and therefore we want it out of Core?

Yeah. I also think while the base DecoratedOperator (and all in airflow/decorators/base.py) should stay in "core" - "task" and other decorators can be easily (or so I think) move to standard (unless there is a good reason not to).

BaseOperator. MappedOperator, DecoratedOperator are all "core" concepts - but @task, @task.bash etc. could be just considered as concrete implementations of those that could live in the standard provider.

@uranusjr - is there a reason why we should not move it ?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.