1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.PYTHON

  • Policy Proposal python3-supported-(min|max) virtual packages

    From Stefano Rivera@21:1/5 to All on Sat Jan 14 18:10:01 2023
    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)
  • From Scott Kitterman@21:1/5 to Stefano Rivera on Sat Jan 14 18:30:01 2023
    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)
  • From Scott Kitterman@21:1/5 to Stefano Rivera on Sat Jan 14 20:40:01 2023
    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)
  • From Stefano Rivera@21:1/5 to All on Sat Jan 14 20:20:02 2023
    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)
  • From Scott Kitterman@21:1/5 to Stefano Rivera on Sat Jan 14 21:00:01 2023
    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)
  • From Stefano Rivera@21:1/5 to All on Sat Jan 14 21:00:01 2023
    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)
  • From Julian Gilbey@21:1/5 to Scott Kitterman on Sat Jan 14 21:50:01 2023
    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)