Skip to content

Run lowest deps checks that include lowest version of cross-provider deps as well #60888

Open

Description

@potiuk

Body

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.

Activity

  1. added
    kind:metaHigh-level information important to the community
    on Jan 21, 2026
  2. 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
  3. Prab-27 commented on Jan 21, 2026

    @Prab-27
    Contributor

    @potiuk , I’d like to participate in this, if it’s fine for me to work on it

  4. potiuk commented on Jan 21, 2026

    @potiuk
    MemberAuthor

    Feel Free.

  5. moved this from Ready to In progress in CI / DEV ENV planned workon Jan 21, 2026
  6. Prab-27 commented on Feb 18, 2026

    @Prab-27
    Contributor

    Working hard; I’ll raise a PR as soon as possible.

  7. potiuk commented on Mar 2, 2026

    @potiuk
    MemberAuthor

    @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.

  8. Prab-27 commented on Mar 3, 2026

    @Prab-27
    Contributor

    I'm working on this

  9. Prab-27 commented on Mar 21, 2026

    @Prab-27
    Contributor

    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 ?

  10. Prab-27 commented on Sep 10, 2026

    @Prab-27
    Contributor

    Restarting my work on this issue !

  11. self-assigned this
    on Oct 15, 2026
  12. Prab-27 commented on Oct 15, 2026

    @Prab-27
    Contributor

    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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:providerskind:metaHigh-level information important to the community

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions