There is no pip package apache-airflow-providers-standard in the official docker image. Why?

[smktpd]

Hi. I don't understand why there is no python (pip) package apache-airflow-providers-standard in the official docker image docker.io/apache/airflow:2.11.0-python3.12?
Shouldn't it be there?

[potiuk]

Because that package was not automatically installed when 2.11 was released - but this is not a problem you can super easily extedn the image and add it following https://airflow.apache.org/docs/docker-stack/build.html

[smktpd]

I don't understand whether I should install it: class PythonOperator seems to be available somehow even without this package, yet the docs say this class is supposedly a part of said package.
Why don't you include it in the images you build?
Is this something that had been forgotten or had it intentionally been omitted?

[potiuk]

You are likely looking at Airflow 3 docs (Python operator has been moved to standard provider in Airflow 3).

Did you look at upgrade does and release notes for provider package and airflow ?

[smktpd]

You are likely looking at Airflow 3 docs (Python operator has been moved to standard provider in Airflow 3).

No, I was looking at the docs of the provider, not Airflow.

Did you look at upgrade does and release notes for provider package and airflow ?

Yes, but it is confusing: while release notes for Airflow v3.0.0 say

Airflow 3.0 completes the migration of several core operators, sensors, and hooks into the new apache-airflow-providers-standard package. This package now includes commonly used components such as:
PythonOperator

yet the docs page for about PythonOperator in 'standard' provider v1.11.1.
It's requirements page simply says

The minimum Apache Airflow version supported by this provider distribution is 2.11.0.

So if that package is for Airflow 2.11.0 and provides PythonOperator - it's pretty logical to think that Airflow 2.11.0 shouldn't have PythonOperator without 'standard' provider's pip package installed. It is not installed in your image, yet somehow the operator is available there, which is confusing.

Even more confusion: the changelog for the provider has first mention of PythonOperator for v0.0.3 dated 2024-12-16 which at that time relied on Airflow 2.9.

[potiuk]

So if that package is for Airflow 2.11.0 and provides PythonOperator - it's pretty logical to think that Airflow 2.11.0 shouldn't have PythonOperator without 'standard' provider's pip package installed. It is not installed in your image, yet somehow the operator is available there, which is confusing.

No. It has nothing to do with logic - it's more jumping to conclusion without understanding the context. See https://airflow.apache.org/docs/apache-airflow/stable/installation/upgrading_to_airflow3.html#step-4-install-the-standard-provider

Allowing standard provider is to ease migration. See upgrading docs from Airflow 2 to 3. T he presence of old "standard" operators in 2.11 is needed for backwards compatibiliity. Removing them would violate SemVer. So if you want to prepare your Dags for migration to 3 you install standard provider (additionally to what you have in 2.11) and then you can convert your Dags to use the standard provider before you attempt to migrate. Thus avoiding big bang. User needs to take deliberate decision on installing standard provider manually if they want to do it. Having it installed and having two implementations of standard providers in two places without users deliberately asking for that would be far more confusing.

[smktpd]

Oh, so basically it is an intended overlap (both code bases [Airflow 2.11's and -standard provider's] provide the same classes/methods) for the sake of smooth migration.
Got it, thanks for clarifying!