Add protocol to define methods relied upon by KubernetesPodOperator#31298
Add protocol to define methods relied upon by KubernetesPodOperator#31298dstandish merged 4 commits intoapache:mainfrom
Conversation
|
@eladkal @potiuk I am surprised to not see cncf in the list of dependencies for google provider, because the GKPO does inherit from KPO. Given that with this we'd be introducing a dep in GKPO that depends on a protocol defined in CNCF, first of all is this even workable? And how should we handle this with regard to deps? |
Subclasses of KubernetesPodOperator, such as GKEStartPodOperator, may use hooks that don't extend KubernetesHook. We use this protocol to document the methods used by KPO and ensure that these methods exist on such other hooks.
da66bf4 to
833d276
Compare
We have them, implicitly. airflow/generated/provider_dependencies.json Line 394 in d3a2dbe When we prepare "generated/provider_dependencies.json", the cross-provider-dependencies are automatically derived by looking at the imports of other providers from a provider - and they are automatically added to the dependencies and made into "extras" of the provider. The cross-provider package dependencies are automatically added as "extras" https://airflow.apache.org/docs/apache-airflow-providers-google/stable/index.html#cross-provider-package-dependencies For example in this case This is a "weak" relation between providers which means that some things in the provider might not work in case the extra is not used when installing the provider (or when by chance the provider from extra is not installed). But if we think that the dependency is so strong that one cannot live by another - we can add explicit dependency (and even add >= explicit version which happened in some cases) in the past.
Given that this is one of about a 160 or so operators in google provider, I'd say the weak relation we have is "good enough". You can make an extremely good use of the 159 or so operators in the google provider, without having cncf.kubernetes one installed. |
|
Btw - maybe thi is what you are after - we could -in fact - make even explicit VERSIONED extra dependency. This is already happening for google provider `provider.yaml': You could add there: And what would happen, if someone does |
| from dataclasses import dataclass | ||
| from datetime import datetime, timedelta | ||
| from typing import TYPE_CHECKING, Generator, cast | ||
| from typing import TYPE_CHECKING, Generator, Protocol, cast |
There was a problem hiding this comment.
Small problem - until end of June, Protocol needs to be imported as:
from airflow.typing_compat import Protocol
ok thanks i will do this |
Yep. Just checked in https://github.com/apache/airflow/pull/31252/files that we are going to have 6.2.0 version of the cncf.kubernetes provider. |
|
I’m trying to bulk-fix the migration errors in #31306. |
|
er i'll just merge, don't think it will create a conflict for you |
Subclasses of KubernetesPodOperator, such as GKEStartPodOperator, may use hooks that don't extend KubernetesHook. We use this protocol to document the methods used by KPO and ensure that these methods exist on such other hooks.
Related: #31266
In #31266, I added the missing methods to GKESPO and test to ensure consistency. With the introduction of this protocol, this test would no longer be needed, though it will require a dependency for google on the latest CNCF provider