Re: Policy Proposal python3-supported-(min|max) virtual packages
On Sat, Jan 14, 2023 at 07:34:59PM +, Scott Kitterman wrote: > Typically though doesn't the python interpreter package provide modules that > are now incorporated? If python3.11 provides python3-tomli, won't that mess > this up? In this case, it doesn't; the Python 3.11 standard library module is called tomllib, presumably to avoid conflicting with the toml or tomli library. (And I'm guessing the package in question imports tomllib if using 3.11 or higher and tomli otherwise.) Best wishes, Julian
Re: Policy Proposal python3-supported-(min|max) virtual packages
On January 14, 2023 7:51:47 PM UTC, Stefano Rivera wrote: >Hi Scott (2023.01.14_19:34:59_+) >> >dh_python3 would have been able to generate >> >python3-tomli | python3-min-version (>= 3.11) >> > >> >instead of >> >python3-tomli | python3 (>> 3.11) >> > >> >Then, once python3.10 was dropped from supported, python3 would >> >Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) >> >> And python3-min-version is a virtual package, so dpgk doesn't need any >> special knowledge to do the right thing, right? I think that's reasonable. > >Yeah. > >> Typically though doesn't the python interpreter package provide modules that >> are now incorporated? If python3.11 provides python3-tomli, won't that mess >> this up? > >I can't recall how this was done historically, but the git history of >python3 and python3-defaults doesn't show any provides like that. The >only one I can see is python3-profiler, which is provided by python3, >not python3.X. > Thanks for checking. I definitely recall it for Python2, but if it's not a Python3 thing, then I think it's good. It would probably be beneficial to have the policy statement have a MUST NOT to say not to do it in the future as that would break this. Scott K
Re: Policy Proposal python3-supported-(min|max) virtual packages
Hi Scott (2023.01.14_19:34:59_+) > >dh_python3 would have been able to generate > >python3-tomli | python3-min-version (>= 3.11) > > > >instead of > >python3-tomli | python3 (>> 3.11) > > > >Then, once python3.10 was dropped from supported, python3 would > >Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) > > And python3-min-version is a virtual package, so dpgk doesn't need any > special knowledge to do the right thing, right? I think that's reasonable. Yeah. > Typically though doesn't the python interpreter package provide modules that > are now incorporated? If python3.11 provides python3-tomli, won't that mess > this up? I can't recall how this was done historically, but the git history of python3 and python3-defaults doesn't show any provides like that. The only one I can see is python3-profiler, which is provided by python3, not python3.X. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Policy Proposal python3-supported-(min|max) virtual packages
On January 14, 2023 7:12:33 PM UTC, Stefano Rivera wrote: >Hi Scott (2023.01.14_17:22:42_+) >> Take the example in #1027947. If this proposal had been in place >> already, what would he have been the generated dependency and how >> would it have worked? > >dh_python3 would have been able to generate >python3-tomli | python3-min-version (>= 3.11) > >instead of >python3-tomli | python3 (>> 3.11) > >Then, once python3.10 was dropped from supported, python3 would >Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) > >The >= vs >> isn't particularly relevant here. At the moment python3 (>> 3.11) >effectively means >= 3.11, because it's always 3.11.something-something. And python3-min-version is a virtual package, so dpgk doesn't need any special knowledge to do the right thing, right? I think that's reasonable. Typically though doesn't the python interpreter package provide modules that are now incorporated? If python3.11 provides python3-tomli, won't that mess this up? Scott K
Re: Policy Proposal python3-supported-(min|max) virtual packages
Hi Scott (2023.01.14_17:22:42_+) > Take the example in #1027947. If this proposal had been in place > already, what would he have been the generated dependency and how > would it have worked? dh_python3 would have been able to generate python3-tomli | python3-min-version (>= 3.11) instead of python3-tomli | python3 (>> 3.11) Then, once python3.10 was dropped from supported, python3 would Provides: python3-min-version (= 3.11), python3-max-version (= 3.11) The >= vs >> isn't particularly relevant here. At the moment python3 (>> 3.11) effectively means >= 3.11, because it's always 3.11.something-something. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Policy Proposal python3-supported-(min|max) virtual packages
On January 14, 2023 5:08:17 PM UTC, Stefano Rivera wrote: >I have proposed a policy change that would permit dh_python3 to generate >dependencies that apply to all currently-supported Python 3 versions: > >https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/13 > >Please review it and give me feedback. > >Matthias: I'm CCing you, because you had concerns when I mentioned this >on IRC. But I hadn't provided a clear description of what I was >proposing. Does this sound like something that works? I read it. I'm not sure I understand how it would work. Take the example in #1027947. If this proposal had been in place already, what would he have been the generated dependency and how would it have worked? Scott K
Policy Proposal python3-supported-(min|max) virtual packages
I have proposed a policy change that would permit dh_python3 to generate dependencies that apply to all currently-supported Python 3 versions: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/13 Please review it and give me feedback. Matthias: I'm CCing you, because you had concerns when I mentioned this on IRC. But I hadn't provided a clear description of what I was proposing. Does this sound like something that works? SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
