FYI. There are some interesting follow-up and discussions with the Astral team - also resulting from some of our Python 3.13 changes...
1) there was an interesting issue where uv installed python-snowflake-client on Python 3.13 and allowed us to generate constraints with, but `pip` refused to install it because all versions were using <3.13 2) turns out it's uv's decision to NOT respect upper bounding on "python-requires" (which `pip` currently respects) - following long time discussions in the packaging community how to treat upper-binding on python-requires. This is an extremely difficult and non-obviously solvable issue (for a number of reasons) = this means that anyone using `uv` to install released 3.0.* airflow distributions can install it on Python 3.13. Not perfect, but also we made the decision that we only recommend `pip` and generally advise --constraints for installation 3) However, that astral team started to consider respecting upper-binding on Python for `uv tool install` - which is the "end user" way how people might install airflow with uv, And I personally think that would be a very nice way to approach the issue. More details in https://github.com/astral-sh/uv/issues/14711 If you feel you might want to chime in :) J. On Mon, Jul 7, 2025 at 4:56 PM Jarek Potiuk <ja...@potiuk.com> wrote: > I feel that we are arriving at a good solution - and with a good reasoning > and proper advice :) > > From the ambiguity of ~= and advising to use >=,< to avoiding < > altogether and doing just `>=` ... Nice! And Concise. > > On Mon, Jul 7, 2025 at 4:43 PM Damian Shaw <ds...@striketechnologies.com> > wrote: > >> Yes, in fact many (all?) universal resolution tools, such as uv, simply >> ignore the upper bound of requires-python when resolving, so it's likely >> not doing what you think it should be doing. >> >> Damian >> >> -----Original Message----- >> From: Jarek Potiuk <ja...@potiuk.com> >> Sent: Monday, July 7, 2025 10:23 AM >> To: dev@airflow.apache.org >> Subject: Re: [DISCUSS] Use ~= for python requires? >> >> It looks like >> https://discuss.python.org/t/requires-python-upper-limits/12663 - it is >> indeed a widely adopted practice to not upper-bind python-requires at all. >> So neither ~=3.10, nor >=3.10,<4 but `>=3.10` seems to be the **right** >> approach. And I am advocating now for changing the warning message (and >> trigger - to also warn when < is used for python-requires) to stay and to >> ask to remove the upper-binding (at least until Python 4 is even considered >> at all). >> >> I raised another PR for that https://github.com/apache/airflow/pull/52980 >> in anticipation that this will be our "preferred python-requires". >> >> J. >> >> On Mon, Jul 7, 2025 at 3:14 PM Jarek Potiuk <ja...@potiuk.com> wrote: >> >> > Makes sense. Maybe we should then mention that in the >> > https://github.com/astral-sh/uv/issues/14422 ? I do not want to "spoil" >> > relationship with Astral, and while I strongly believe that they >> > should not make such decisions unilaterally and forcing people to >> > change their choices, having a `pip` maintainer saying that this is a >> > good idea, and even pointing that ~3.10 should really be replaced by >> > >=3.10 and that it makes little sense to use ~3.10, is turning that >> > into a "community decision" - and I will be more than happy to simply >> follow it. >> > >> > J. >> > >> > On Mon, Jul 7, 2025 at 3:08 PM Tzu-ping Chung >> > <t...@astronomer.io.invalid> >> > wrote: >> > >> >> You don’t find anyone actively saying it’s bad, but you also would >> >> not find anyone recommending it with a good reason. With Python’s >> >> versioning scheme, having <4 makes as much sense as (random example) >> <3.10. >> >> >> >> I believe the trend was started by Poetry having all version range >> >> specifications to use ^ by default when you do “poetry add.” It’s a >> >> reasonable default across the board, but unless you’re using a >> >> similar automated tool, adding an upper cap to the supported Python >> >> version is cargo cult. Extra characters without any reasoning behind >> them. >> >> >> >> -- >> >> Sent from my iPhone >> >> >> >> > On 7 Jul 2025, at 13:39, Jarek Potiuk <ja...@potiuk.com> wrote: >> >> > >> >> > >> >> >> >> >> >> Note that while, as mentioned, ~= is a standard and well-supported >> >> > operator, it is generally NOT RECOMMENDED to be used for Python >> >> > version specification. It is also not recommended to use the >> >> > equivalent >> >> expression >> >> > composed with >= and <. >> >> > >> >> > Interesting - could you point where it is specified that it is not >> >> > recommended ? (Not that I am complaining, I understand that Python >> >> > does not follow SemVer, but I look hard and have not found any >> >> > place where anyone would say it's not recommended - that was the >> >> > first time I hear >> >> it, >> >> > but If I know that Python Packaging actually made that >> >> > recommendation, I would be more than happy to just switch and not >> make any fuss about it. >> >> > >> >> >> On Mon, Jul 7, 2025 at 1:12 PM Tzu-ping Chung >> >> >> <t...@astronomer.io.invalid >> >> > >> >> >> wrote: >> >> >> >> >> >> Note that while, as mentioned, ~= is a standard and well-supported >> >> >> operator, it is generally NOT RECOMMENDED to be used for Python >> >> >> version specification. It is also not recommended to use the >> >> >> equivalent >> >> expression >> >> >> composed with >= and <. >> >> >> >> >> >> Python does not use semantic versioning, and backward incompatible >> >> changes >> >> >> are made in x.y releases (e.g. 3.10 can contain incompatibilities >> >> >> to >> >> 3.9). >> >> >> Setting <4 (or any single-segment version) is therefore arbitrary >> >> >> and divorced of any practicality. >> >> >> >> >> >> I would highly suggest Airflow to simply change ~= to a simple >= >> >> without >> >> >> an upper limit. >> >> >> >> >> >> TP >> >> >> >> >> >> -- >> >> >> Sent from my iPhone >> >> >> >> >> >>>> On 7 Jul 2025, at 12:22, Amogh Desai <amoghdesai....@gmail.com> >> >> wrote: >> >> >>> >> >> >>> Thanks Jarek. >> >> >>> >> >> >>> I do not have a strong objection to either form. Both the ways >> >> >>> are functionally the same and valid per PEP 440. >> >> >>> >> >> >>> If I had to slightly lean one way, I’d prefer ~=3.10 for its >> >> >>> brevity >> >> and >> >> >>> simplicity. That said, I would also understand why some might >> >> >>> prefer the more explicit >=3.10,<4, especially in a big >> >> >> project >> >> >>> like ours where there are lot of newcomers coming in all the >> >> >>> time. >> >> >>> >> >> >>> I am ok to go with whatever the community prefers here. I am more >> >> >>> interested in consistency in one way or another. >> >> >>> >> >> >>> Thanks & Regards, >> >> >>> Amogh Desai >> >> >>> >> >> >>> >> >> >>>> On Mon, Jul 7, 2025 at 3:22 PM Pavankumar Gopidesu < >> >> >> gopidesupa...@gmail.com> >> >> >>>> wrote: >> >> >>>> >> >> >>>> Thanks Jarek, >> >> >>>> >> >> >>>> I am just catching up with this discussion. I agree that this is >> >> >>>> unilaterally forcing us to make changes, though the one (~=3.10) >> >> >>>> is >> >> also >> >> >>>> the standard one we have been using. >> >> >>>> >> >> >>>> I am in favour of using our existing convention ~=3.10. >> >> >>>> >> >> >>>> Pavan >> >> >>>> >> >> >>>>> On Mon, Jul 7, 2025 at 10:12 AM Jarek Potiuk <ja...@potiuk.com> >> >> wrote: >> >> >>>>> >> >> >>>>> Hello here, >> >> >>>>> >> >> >>>>> If you have not noticed - we have a little bit of drama because >> >> >>>>> in >> >> the >> >> >>>>> latest `uv` version, Astral unilaterally decided to make the >> >> `~=3.10` >> >> >>>>> de-facto invalid specification. >> >> >>>>> >> >> >>>>> The `~=3.10` is a perfectly valid specification widely >> >> >>>>> recognized >> >> as >> >> >>>>> `>=3.10,<4` and specified like that (named "Compatible >> >> >>>>> Release") in >> >> >>>>> https://peps.python.org/pep-0440/#compatible-release and even >> >> >>>>> if >> >> the >> >> >>>>> wording in the PEP is slightly ambiguous for the semantics of >> >> >>>>> it - >> >> it >> >> >> is >> >> >>>>> widely recognized, quite heavily used and all Python tooling >> >> properly >> >> >>>>> interpret it in the way described above. >> >> >>>>> >> >> >>>>> Yet the Astral team decided - unilaterally, that this is an >> >> ambiguous >> >> >> and >> >> >>>>> misleading specification and started issuing a warning about it. >> >> >>>> Initially, >> >> >>>>> the warning was pretty mysterious for workspace, because it did >> >> >>>>> not >> >> >> tell >> >> >>>>> which pyproject.toml it came from (we had it in all providers >> >> >>>>> and >> >> >>>> breeze) - >> >> >>>>> so after they implemented a fix, this turned into about a 100 >> >> >>>> unsilenceable >> >> >>>>> warnings every time you run `uv sync`. This happened after I >> >> complained >> >> >>>>> about this in the PR and proposed that there should be both - >> >> >>>>> better message and a way to silence the warning for maintainers >> >> >>>>> that they >> >> know >> >> >>>>> what they are doing) - yet uv 7.9.19 just made the situation >> >> >>>>> worse >> >> by >> >> >>>>> ballooning the number of warnings and still not allowing to >> >> >>>>> silence >> >> it. >> >> >>>>> >> >> >>>>> We are still waiting on a decision what Astral team will do in >> >> >>>>> https://github.com/astral-sh/uv/issues/14422, Unfortunately >> >> >>>>> there >> >> is >> >> >> no >> >> >>>>> community to make decisions there - this is a unilateral >> >> >>>>> decision of >> >> >>>> Astral >> >> >>>>> team what they do, even if ~=3.10 is perfectly valid and >> >> >>>>> recognized specification, that IMHO is not up to Astral team to >> >> >>>>> make people >> >> change >> >> >>>>> their way. >> >> >>>>> >> >> >>>>> So for now we are literally being forced by Astral to change >> >> >>>>> the >> >> way we >> >> >>>>> declare python compatibility - PR is here >> >> >>>>> https://github.com/apache/airflow/pull/52967 . The way how `uv` >> >> >> workflow >> >> >>>>> works makes it impossible to keep `~=3.10` - because every time >> >> >>>>> you >> >> run >> >> >>>> `uv >> >> >>>>> sync` - in our case literally several times a day you have 1.5 >> >> pages of >> >> >>>>> warnings in your terminal. So it's not a "recommendation" - we >> >> >>>>> are >> >> >> forced >> >> >>>>> to change it. >> >> >>>>> >> >> >>>>> I do not particularly like being forced like that - for the >> >> >>>>> "PEP >> >> >>>> compliant" >> >> >>>>> and "standard" feature by the Astral team - but for now I >> >> >>>>> created >> >> the >> >> >>>>> temporary fix - and hopefully the decision will be reversed and >> >> >>>>> we >> >> will >> >> >>>> be >> >> >>>>> able to silence the warning - if we choose to do so. >> >> >>>>> >> >> >>>>> Speaking of which: >> >> >>>>> >> >> >>>>> Assuming that we have a choice (we do not have it now) - what >> >> >>>>> would >> >> be >> >> >>>> your >> >> >>>>> preference: >> >> >>>>> >> >> >>>>> * Should we continue using ~3.10 ? >> >> >>>>> * Or should we switch to >=3.10,<4 ? >> >> >>>>> >> >> >>>>> I'd love to hear - regardless of the forceful change now - what >> >> >>>>> is >> >> the >> >> >>>>> preference of the community members. I have no "strong" >> >> preferences, I >> >> >>>>> slightly prefer the `~3.10` as it is more concise. But I know >> >> >>>>> others >> >> >>>> might >> >> >>>>> have a different preference. And assuming that the Astral team >> >> >>>>> will >> >> >> stop >> >> >>>>> forcing us to "voluntarily choose" the latter, I would love >> >> >>>>> that our community makes that choice on their own. >> >> >>>>> >> >> >>>>> What do you prefer? >> >> >>>>> >> >> >>>>> J. >> >> >>>>> >> >> >>>> >> >> >> >> >> >> ------------------------------------------------------------------ >> >> >> --- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >> >> >> For additional commands, e-mail: dev-h...@airflow.apache.org >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >> >> For additional commands, e-mail: dev-h...@airflow.apache.org >> >> >> >> >> ________________________________ >> Strike Technologies, LLC (“Strike”) is part of the GTS family of >> companies. Strike is a technology solutions provider, and is not a broker >> or dealer and does not transact any securities related business directly >> whatsoever. This communication is the property of Strike and its >> affiliates, and does not constitute an offer to sell or the solicitation of >> an offer to buy any security in any jurisdiction. It is intended only for >> the person to whom it is addressed and may contain information that is >> privileged, confidential, or otherwise protected from disclosure. >> Distribution or copying of this communication, or the information contained >> herein, by anyone other than the intended recipient is prohibited. If you >> have received this communication in error, please immediately notify Strike >> at i...@striketechnologies.com, and delete and destroy any copies hereof. >> ________________________________ >> >> CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any attachments >> are intended solely for the addressee. This transmission is covered by the >> Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The >> information contained in this transmission is confidential in nature and >> protected from further use or disclosure under U.S. Pub. L. 106-102, 113 >> U.S. Stat. 1338 (1999), and may be subject to attorney-client or other >> legal privilege. Your use or disclosure of this information for any purpose >> other than that intended by its transmittal is strictly prohibited, and may >> subject you to fines and/or penalties under federal and state law. If you >> are not the intended recipient of this transmission, please DESTROY ALL >> COPIES RECEIVED and confirm destruction to the sender via return >> transmittal. >> >
