potiuk commented on PR #34257:
URL: https://github.com/apache/airflow/pull/34257#issuecomment-1712930647
> You mentioned the conflict part - but that is not the only thing.
Providers may be updated seperatly from core. If user will bump google provider
you are now also force him to update common.sql provider. That requires more
checks, more testing, more time and what if this version of sql provider
contains a bug? It happens... Even if we say that everything should be the
same, some users take the caution way and sometimes its just the procedure. We
should recognize this. I myself been there. I prefer to let users decide when
they want to update each provider and not force them into doing something they
did not intend unless there is a very good reason.
I disagree. Most users don't care and don't know about transitional
dependencies. Common.sql is not useful on it's own. If there are no breaking
changes, it does not matter for them. We make the decisions about which
transitional dependencies are needed for the "useful" ones. They (at most) care
about direct dependendencies ("google" in this case) and they have no idea
about the others.
In a way it's contradicting what with "constraints" - with constraints we
decide for the users not only what direct dependencies they have but also all
700 transitive ones. With those coonstraints we say the users "you install them
and you are good".
What you are really saying is " let's not limit the dependent dependency
because it might mean some unexpected errors will happen - AGAINST maintainer
intentions". But what "min-version" of common-sql is saying is "we KNOW that if
you use older version of common-sql - this feature will not work and we prevent
the user from making the mistake". So what we are trading here is "maybe there
is some future errorr" vs. "we prevent the user from a known error". I prefer
to take the risk - especially that the user can always downgrade google
provider if that "uknown" error occurs.
--
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]
