-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
Conversation
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
Relates to #43200 |
Just failing with the known WTForms issue. Merging |
Can someone test if this lets If not then add |
…can work. (apache#43217)" This reverts commit 892b2f1.
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
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
"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 |
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
We already have this:
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
anduv sync
both worth, which should be the requiredstep 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.