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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On January 14, 2023 5:08:17 PM UTC, Stefano Rivera <stefanor@debian.org> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On January 14, 2023 7:12:33 PM UTC, Stefano Rivera <stefanor@debian.org> wrote: >Hi Scott (2023.01.14_17:22:42_+0000)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Scott (2023.01.14_17:22:42_+0000)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On January 14, 2023 7:51:47 PM UTC, Stefano Rivera <stefanor@debian.org> wrote: >Hi Scott (2023.01.14_19:34:59_+0000)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Scott (2023.01.14_19:34:59_+0000)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 14, 2023 at 07:34:59PM +0000, 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)