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. >
