Temporarily switch to use >=,< pattern instead of ~=
#52967
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
potiuk
requested review from
Fokko,
amoghrajesh,
ashb,
bolkedebruin,
eladkal,
gopidesupavan,
hussein-awala,
jedcunningham,
josh-fell,
jscheffl,
mik-laj,
mobuchowski and
vincbeck
as code owners
boring-cyborg
bot
added
area:providers
backport-to-v3-1-test
boring-cyborg
bot
added
provider:apprise
provider:arangodb
provider:asana
provider:atlassian-jira
provider:celery
provider:cloudant
provider:cncf-kubernetes
Our contributors are affected by an unilateral decision of Astral team to raise an unsilenceable warning when valid `~=` so we are literaly being forced to change it - at leas temporarily until decision is made on astral-sh/uv#14422. We are not too happy to do it, but otherwise if someone updates to 0,7.19 version of `uv` they get a ton of warnings that they can do literally nothing about. So maintainers - more or less through Astral decision and to make our contributor happy are forced to change the way how we are declaring the version support. I hope that we will be able to silence the warning and then make a conscious decision as maintainers to use whatever style of require-python we feel better with. For now however we will change it to the variant that is "recommended" by uv to silence the warning - because we literally have no other choice.
potiuk
force-pushed
the
temporary-use-more-complex-requires-python
branch
from
c9f408c to
908f840
Compare
amoghrajesh
approved these changes
Jul 7, 2025
Contributor
amoghrajesh
left a comment
amoghrajesh
left a comment
There was a problem hiding this comment.
Let's unblock the problems for now +1
gopidesupavan
approved these changes
Jul 7, 2025
Backport failed to create: v3-0-test. View the failure log Run details
You can attempt to backport this manually by running: cherry_picker fbc8f06 v3-0-testThis should apply the commit to the v3-0-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continue |
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Jul 7, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose.
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Jul 7, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose.
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Jul 7, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose.
potiuk
added a commit
that referenced
this pull request
Jul 7, 2025
Follow up after #52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose.
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Jul 7, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose. (cherry picked from commit e9eb481)
potiuk
added a commit
to potiuk/airflow
that referenced
this pull request
Jul 7, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose. (cherry picked from commit e9eb481)
potiuk
added a commit
that referenced
this pull request
Jul 7, 2025
Follow up after #52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose. (cherry picked from commit e9eb481)
kaxil
pushed a commit
that referenced
this pull request
Jul 9, 2025
Follow up after #52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose. (cherry picked from commit e9eb481)
HsiuChuanHsu
pushed a commit
to HsiuChuanHsu/airflow
that referenced
this pull request
Jul 10, 2025
Our contributors are affected by an unilateral decision of Astral team to raise an unsilenceable warning when valid `~=` so we are literaly being forced to change it - at leas temporarily until decision is made on astral-sh/uv#14422. We are not too happy to do it, but otherwise if someone updates to 0,7.19 version of `uv` they get a ton of warnings that they can do literally nothing about. So maintainers - more or less through Astral decision and to make our contributor happy are forced to change the way how we are declaring the version support. I hope that we will be able to silence the warning and then make a conscious decision as maintainers to use whatever style of require-python we feel better with. For now however we will change it to the variant that is "recommended" by uv to silence the warning - because we literally have no other choice.
HsiuChuanHsu
pushed a commit
to HsiuChuanHsu/airflow
that referenced
this pull request
Jul 10, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose.
kaxil
pushed a commit
that referenced
this pull request
Jul 11, 2025
Follow up after #52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose. (cherry picked from commit e9eb481)
kaxil
pushed a commit
that referenced
this pull request
Jul 11, 2025
Follow up after #52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose. (cherry picked from commit e9eb481)
stephen-bracken
pushed a commit
to stephen-bracken/airflow
that referenced
this pull request
Jul 15, 2025
Our contributors are affected by an unilateral decision of Astral team to raise an unsilenceable warning when valid `~=` so we are literaly being forced to change it - at leas temporarily until decision is made on astral-sh/uv#14422. We are not too happy to do it, but otherwise if someone updates to 0,7.19 version of `uv` they get a ton of warnings that they can do literally nothing about. So maintainers - more or less through Astral decision and to make our contributor happy are forced to change the way how we are declaring the version support. I hope that we will be able to silence the warning and then make a conscious decision as maintainers to use whatever style of require-python we feel better with. For now however we will change it to the variant that is "recommended" by uv to silence the warning - because we literally have no other choice.
stephen-bracken
pushed a commit
to stephen-bracken/airflow
that referenced
this pull request
Jul 15, 2025
Follow up after apache#52967 -> from later discussions it turned out that it's not really the ~= that is wrong and ambiguous, but that just upper-binding of Python version is generally considered as a bad idea - and it's not Astral's view but it's general consensus that upper-binding of "python-requires" is bad. Since ~= implies upper-binding, simply replacing it with >= is likely the best option we can choose.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our contributors are affected by an unilateral decision of Astral team to raise an unsilenceable warning when valid
~=so we are literaly being forced to change it - at leas temporarily until decision is made on astral-sh/uv#14422.We are not too happy to do it, but otherwise if someone updates to 0,7.19 version of
uvthey get a ton of warnings that they can do literally nothing about. So maintainers - more or less through Astral decision and to make our contributor happy are forced to change the way how we are declaring the version support.I hope that we will be able to silence the warning and then make a conscious decision as maintainers to use whatever style of require-python we feel better with. For now however we will change it to the variant that is "recommended" by uv to silence the warning - because we literally have no other choice.
^ 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.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.