You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Run lowest deps checks that include lowest version of cross-provider deps as well #60888
Currently we run lowest-deps tests for individual providers, however, they do not really test if the min version of cross-provider dependency is good - because they are installing all providers from sources. This is a problem especially for common.compat - because all providers are using it and they have different min-version requirements.
We are using uv sync --resolution lowest-direct - but in the workspace, anyhow the source version of other providers are used.
We should be able to lower-down also cross-provider deps. This can be done by either:
if possible in uv - exclude other providers from workspace during the uv-sync
or
if not posible to do - manualy update the workspace to remove those providers from workspace definition so that they are installed from PyPI
This should be skipped for all packages with # use next version in the provider being tested.
Committer
I acknowledge that I am a maintainer/committer of the Apache Airflow project.
changed the title [-]Run lowest deps checks that include lowest version of cross-provider deps as well\[/-][+]Run lowest deps checks that include lowest version of cross-provider deps as well[/+]on Jan 21, 2026
This is not meant to discourage your contribution — quite the opposite! You are still very welcome to work on this issue and submit a PR for it. Simply comment that you are working on it and open a PR when ready.
We found that formal assignments were not working well, as they often prevented others from contributing when the assignee was not actively working on the issue.
I tried, but first solution (if possible in uv - exclude other providers from workspace during the uv-sync. ) not possible since the uv sync internally handle this using uv lock
I’m working on the second - if not possible to do - manually update the workspace to remove those providers from the workspace definition so that they are installed from PyPI
I followed this approach - removed common-compact from the workspace member or also dev if mentioned - that way we can remove it from installing from sources during uv-sync. But I don’t understand what type of group we can add this dependency to so it can be used and also installed from PyPI, or does it get worse?
I think it might be better if we handle this type of dependency from the uv side - for example, by implementing a flag(# use next version) like #pypi, or a mechanism like an Index flag for only PYPI. In that case, we’d need to implement this as a workspace member that can only be installed from PyPI (e.g., index = PyPI). By this way we can handle not only this but other cross provider dependency (If raise in future ) ? IF This solutions works fine for us I'd happy to riase a PR there -
@potiuk Would you please share your thoughts on this ?
I'm really sorry, @dabla@potiuk , that I couldn't complete this over the last few days. I have been busy - some family responsibilities and a job search and 2 open PRs
I will be much more careful with my words next time!
Activity
[-]Run lowest deps checks that include lowest version of cross-provider deps as well\[/-][+]Run lowest deps checks that include lowest version of cross-provider deps as well[/+]Prab-27 commentedon Jan 21, 2026
@potiuk , I’d like to participate in this, if it’s fine for me to work on it
potiuk commentedon Jan 21, 2026
Feel Free.
Prab-27 commentedon Feb 18, 2026
Working hard; I’ll raise a PR as soon as possible.
potiuk commentedon Mar 2, 2026
@Prab-27 We are unassigning you from this issue as part of our updated assignment policy.
This is not meant to discourage your contribution — quite the opposite! You are still very welcome to work on this issue and submit a PR for it. Simply comment that you are working on it and open a PR when ready.
We found that formal assignments were not working well, as they often prevented others from contributing when the assignee was not actively working on the issue.
Prab-27 commentedon Mar 3, 2026
I'm working on this
Prab-27 commentedon Mar 21, 2026
I tried, but first solution (
if possible in uv - exclude other providers from workspace during the uv-sync.) not possible since the uv sync internally handle this usinguv lockI’m working on the second -
if not possible to do - manually update the workspace to remove those providers from the workspace definition so that they are installed from PyPII followed this approach - removed
common-compactfrom theworkspace memberor alsodevif mentioned - that way we can remove it from installing from sources during uv-sync. But I don’t understand what type of group we can add this dependency to so it can be used and also installed from PyPI, or does it get worse?I think it might be better if we handle this type of dependency from the uv side - for example, by implementing a flag
(# use next version) like #pypi, or a mechanism like anIndex flag for only PYPI. In that case, we’d need to implement this as a workspace member that can only be installed from PyPI (e.g., index = PyPI). By this way we can handle not only this but other cross provider dependency (If raise in future ) ? IF This solutions works fine for us I'd happy to riase a PR there -@potiuk Would you please share your thoughts on this ?
Prab-27 commentedon Sep 10, 2026
Restarting my work on this issue !
Prab-27 commentedon Oct 15, 2026
I'm really sorry, @dabla @potiuk , that I couldn't complete this over the last few days. I have been busy - some family responsibilities and a job search and 2 open PRs
I will be much more careful with my words next time!