Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update cloudant versions to be py-version aware so uv lock can work. #43217

Merged
merged 1 commit into from
Oct 21, 2024

Conversation

ashb
Copy link
Member

@ashb ashb commented Oct 21, 2024

We already have this:

excluded-python-versions:
  # ibmcloudant transitively brings in urllib3 2.x, but the snowflake provider has a dependency that pins
  # urllib3 to 1.x on Python 3.9; thus we exclude those Python versions from taking the update
  # to ibmcloudant.
  # See #21004, #41555, and https://github.com/snowflakedb/snowflake-connector-python/issues/2016
  - "3.9"

However when uv is looking at requirements it doesn't/can't respect this field, so we have to make
the dependency aware of python version too.

This makes uv lock and uv sync both worth, which should be the required
step for switching uv to the local venv workflow.


^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

When we are building th provider dists we exclude 3.9 support, but when uv is
looking at requrements it doesn't/can't respect this field, so we have to make
the depenedency aware of python version too.

This makes `uv lock` and `uv sync` both worth, which should be the required
step for switching uv to the local venv workflow
@ashb
Copy link
Member Author

ashb commented Oct 21, 2024

Relates to #43200

@ashb
Copy link
Member Author

ashb commented Oct 21, 2024

Just failing with the known WTForms issue. Merging

@ashb ashb merged commit 892b2f1 into main Oct 21, 2024
82 of 104 checks passed
@ashb ashb deleted the uv-lock-fixes-urllib3-ibmcloudant branch October 21, 2024 13:42
@ashb
Copy link
Member Author

ashb commented Oct 21, 2024

Can someone test if this lets uv sync work for them now.

If not then add - 'ibmcloudant==0.7.0 ; python_version < "3.10"' and then breeze static-checks -t update-providers-dependencies -a

potiuk added a commit to potiuk/airflow that referenced this pull request Oct 21, 2024
harjeevanmaan pushed a commit to harjeevanmaan/airflow that referenced this pull request Oct 23, 2024
apache#43217)

When we are building th provider dists we exclude 3.9 support, but when uv is
looking at requrements it doesn't/can't respect this field, so we have to make
the depenedency aware of python version too.

This makes `uv lock` and `uv sync` both worth, which should be the required
step for switching uv to the local venv workflow
PaulKobow7536 pushed a commit to PaulKobow7536/airflow that referenced this pull request Oct 24, 2024
apache#43217)

When we are building th provider dists we exclude 3.9 support, but when uv is
looking at requrements it doesn't/can't respect this field, so we have to make
the depenedency aware of python version too.

This makes `uv lock` and `uv sync` both worth, which should be the required
step for switching uv to the local venv workflow
@perry2of5
Copy link
Contributor

Can someone test if this lets uv sync work for them now.

If not then add - 'ibmcloudant==0.7.0 ; python_version < "3.10"' and then breeze static-checks -t update-providers-dependencies -a

"uv sync" worked for me, but it creates a "uv.lock" file which isn't in version control and isn't in .gitignore. Possibly we want to add it to github based off this: https://docs.astral.sh/uv/guides/projects/#uvlock

ellisms pushed a commit to ellisms/airflow that referenced this pull request Nov 13, 2024
apache#43217)

When we are building th provider dists we exclude 3.9 support, but when uv is
looking at requrements it doesn't/can't respect this field, so we have to make
the depenedency aware of python version too.

This makes `uv lock` and `uv sync` both worth, which should be the required
step for switching uv to the local venv workflow
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants