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.
