potiuk commented on PR #31298:
URL: https://github.com/apache/airflow/pull/31298#issuecomment-1548559339

   > @eladkal @potiuk I am surprised to not see cncf in the list of 
dependencies for google provider, because the GKPO does inherit from KPO.
   > 
   
   It does, implicitly. 
https://github.com/apache/airflow/blob/d3a2dbe028e4a8c2da9fcb2b3257e2117c413a73/generated/provider_dependencies.json#L394
 
   
   When we prepare "generated/provider_dependencies.json", the 
cross-provider-dependencies are automatically derived by looking at teh imports 
of other providers from a provider - and they are automatically added to the 
dependencies and "extras" of the provider:
   
   Cross provider package dependencies as "extras" 
https://airflow.apache.org/docs/apache-airflow-providers-google/stable/index.html#cross-provider-package-dependencies
 
   
   For example in this case `pip install 
apache-airflow-providers-google[cncf.kubernetes]` will automatically install 
the cncf.kubernetes provider.
   
   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 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?
   
   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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to