potiuk edited a comment on pull request #21235: URL: https://github.com/apache/airflow/pull/21235#issuecomment-1025762256
> Hmm, do we have a mechanism to limit SQLAlchemy < 1.4 _in the constraints file_, but not in the actual package metadata? This way we can “officially” only support <1.4, but someone adventurous enough to want 1.4+ can still have that without the package metadata blocking the possibility. I feel that’d be a better approach. Yes. We can do that as well. We already do that in few other cases and that's also a possibilitty. The way we do that we add limitation in the Dockerfile.ci (this image is used in CI to prepare the constraints): https://github.com/apache/airflow/blob/v2-2-test/Dockerfile.ci#L276 Actually I toyed with that idea too, but I thought that `install_requires` is a bit safer as SQLALchemy is really important piece for us. I think this case is actually a very nice supportive (and not strawman) case to the proposal I made here: https://lists.apache.org/thread/250pfvogkqb31g2vj5p0yz3ntz5qj1ht Sqlalchemy for me is really important piece of Airflow and even small change might impact us a lot - for example performance of certain queries might change dramaticaly if SqlAlchemy changes the way how they are generated - even if for them this will be a "small change" and results might be ''catastrophic'. As I explained in my latest proposal there, I think we should identifty all the "really important" dependencies (few of them) and upper-bound them, all the rest we should not. This way we could take a "deliberate" effort to migrate to higher versions (as we do now in `main` trying to fix it and then later release it in 2.3.0 with enough manual testing. Just having a few of those, will make sure that we can manage the upper-bounds "deliberately". All the rest can easily rely on constraints. My point here is that sqlalchemy is on top of the list of those deps which should be upperbound (if we decide to upperbound dependencies). So if we agreee that sometimes we do upper-bound, IMHO we should do it here. But if we decide to relax it, I am also fine (but then IMHO we should relax all the upperbound limits in this case). -- 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]
