Fix dependencies of standard provider

[potiuk]

Standard provider should have virtualenv as dependency set as it has PythonVirtualenvOperator that needs it. Also it should have min airflow version 2.8.0 same as all other providers.

---

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

[gopidesupavan]

I believe changes required here also BASE_PROVIDERS_COMPATIBILITY_CHECKS

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/global_constants.py#L563 ?

remove-providers: standard from 2.8.4 and 2.9.3

[potiuk]

I believe changes required here also BASE_PROVIDERS_COMPATIBILITY_CHECKS

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/global_constants.py#L563 ?

remove-providers: standard from 2.8.4 and 2.9.3

GREAT POINT

[potiuk]

I will merge it first to fix main though, and then wil make a follow up PR @gopidesupavan

[potiuk]

Follow up PR in #43556

[jscheffl]

Mhm, I am thinking about this as dependency... so in new Airflow Standard provider will be a standard install dependency, this has a standard dependency to virtualenv...
So far ths was always optional, even the examples excluded parts if virtualenv was not available as dependency. Do we really want to make this a pre-requisite?

Personally I think it is not harming but we change the default dependencies here. (Compared to 2.x line where no dependecy was modelled)

[potiuk]

Yeah. Thought about it too. No harm I think. It's been always installed anyway in most cases. And the problem is that if we add it as provider's optional dependency - then almost never will actually install it, while PythonVirtualEnv operator is one that is pretty used.

So I think we should eventually remove the virtualenv extra from airflow and have it always installed.

Another option is - we migh change PythonVirtualenv to use the built-in venv.

Which actually might be a very good idea. WDYT?

[jscheffl]

COmpared to the authors of virtualenv I don't see a real benefir over the included venv. Might be a clever small change.

Otherwise - much cooler would be if UV is supported. We had some discussions in slack... not that pre-commit gets uv support on main-line bewfore we have Airflow 3 out :-D

[potiuk]

I'd be for both - venv (only) and uv (optional) support in the new PythonVirtualenv in provider.

[potiuk]

First part fixed in #43568