1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

  • [gentoo-dev] Re: [RFC] Splitting dev-lang/python into per-slot packages

    From Luca Barbato@21:1/5 to All on Sat Oct 12 11:00:01 2024
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the
    overall experience would be an improvement.

    With your proposed solution, if an user wants to have any version of
    python what should ask to emerge?

    An alternative for freethreading support wouldn't be to install both
    from the same package python-3.14 and have the two PYTHON_TARGETS ?

    lu

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Luca Barbato on Sat Oct 12 11:20:01 2024
    On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the overall experience would be an improvement.

    5 are too many?

    With your proposed solution, if an user wants to have any version of
    python what should ask to emerge?

    Can you actually imagine having a Gentoo system with no Python
    preinstalled, with an user actually needing to emerge one?

    In fact, even today "emerge dev-lang/python" is probably a bad solution,
    as it will lead to a beta/rc version on an ~arch system most
    of the time.

    An alternative for freethreading support wouldn't be to install both
    from the same package python-3.14 and have the two PYTHON_TARGETS ?

    I don't understand.

    --
    Best regards,
    Michał Górny


    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcKPdISHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQODqYH/3cV+bpKaoRcykeq9gembOucOekXBKwV kxSVeral9och0z180Egcg+2f7ZBu92jhmWszTAS24t8g0gH1ZqsB1Lrm4BlXcAMm ykt47qse82C4K07+k3vtrYWwI/0L4i6uD03LM0OAH/4KqVW1r4PXgP+or2TWNGQx EwN4GQTOK3P8MTA680iQzmNBKT+A207FDBSY0cLqWFTATmV6tcZ4sep++RxvIB+G DhZHwdQSw3VhYH8k+r72mPCl/xKrZIIj04ttcvcHXrEAqaUQV9vK39CeAW2yX3NC wY13V6stT1LCHnMOj9jFqHhPT3vQJTWrJyUhKJy92V04MS0Wn/5OUeM=
    =huqc
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to All on Sat Oct 12 15:10:01 2024
    On Sat, 2024-10-12 at 17:30 +0500, Anna (cybertailor) Vyalkova wrote:
    On 2024-10-12 11:13, Michał Górny wrote:
    On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the overall experience would be an improvement.

    5 are too many?

    Absolutely no, and your proposal seems to solve the shortcomings of
    slotting given the limitations. Just Python is not the only language
    with multiple simultaneous versions supported in Gentoo (Ruby comes to
    mind first), and it opens a slippery slope.

    I still find this weak, compared to ~20k packages in Gentoo right now.

    Is there anything that makes Python unique enough to stand out from conventions estabilished for packaging other languages? Or would it essentially lead to a new policy?

    Python pretty much sets the quality standards for Gentoo these days.

    --
    Best regards,
    Michał Górny


    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcKdIISHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOFiUH/R+BSHi8R0koSiBakO1D34BBmln3uFd6 7Q6nTVfcAz/XVEJz94DSo21Zv0RdIKAk6Kjhv9Mzb87wH/akURpkIE4bgDcW+Wf4 mqm32tfmgTkbvd8fDXcwmBygpVuTuc9CGQUXLiuQ0+heRzXJkzcVTiSPCjzenMxR uP+xPQP39XVk9sDeRRm+sl8jrfaED3aVSEwqvL/kLVJ9XueBP1Hh0NpngLntVWGv +3KT86shycwvMepWOl5c2Hf/+jGfZItOi/yBUdgivlDuRRo9uGDuZ0CNHU2XZsRz 5fnUA7LiwVniFRPD9gfv/ST4zwHePg5kFcYR54Xk/hYVa0I+Zepws+E=
    =VJZv
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anna (cybertailor) Vyalkova@21:1/5 to All on Sat Oct 12 14:40:02 2024
    On 2024-10-12 11:13, Michał Górny wrote:
    On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the
    overall experience would be an improvement.

    5 are too many?

    Absolutely no, and your proposal seems to solve the shortcomings of
    slotting given the limitations. Just Python is not the only language
    with multiple simultaneous versions supported in Gentoo (Ruby comes to
    mind first), and it opens a slippery slope.

    Is there anything that makes Python unique enough to stand out from
    conventions estabilished for packaging other languages? Or would it
    essentially lead to a new policy?


    (I'm satisfied with using 'package.mask' and 'package.accept_keywords'
    to prevent "greedy" upgrades, if that matters)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Barbato@21:1/5 to All on Sat Oct 12 15:10:01 2024
    On 12/10/24 11:13, Michał Górny wrote:
    On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the
    overall experience would be an improvement.

    5 are too many?

    potentially it is python_{version}_{variants} so at least 10*2 assuming
    we keep around 3.{N..N+5} and we have two worthy variants.

    Plus the chore of treecleaning older packages. Not sure if it is worth it.

    With your proposed solution, if an user wants to have any version of
    python what should ask to emerge?

    Can you actually imagine having a Gentoo system with no Python
    preinstalled, with an user actually needing to emerge one?

    right now if I need a specific version of python I have to do emerge
    =python-N* and usually it works as intended.

    people would have to get used to do emerge python_{that specific N}


    In fact, even today "emerge dev-lang/python" is probably a bad solution,
    as it will lead to a beta/rc version on an ~arch system most
    of the time.

    An alternative for freethreading support wouldn't be to install both
    from the same package python-3.14 and have the two PYTHON_TARGETS ?

    I don't understand.

    emerge =python-3.14 would install both a non-freethreading and a
    freethreading version and it would satisfy 3_14 and 3_14t at the same.

    lu

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=@21:1/5 to Luca Barbato on Sat Oct 12 15:10:01 2024
    On Sat, 2024-10-12 at 15:00 +0200, Luca Barbato wrote:
    On 12/10/24 11:13, Michał Górny wrote:
    On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the overall experience would be an improvement.

    5 are too many?

    potentially it is python_{version}_{variants} so at least 10*2 assuming
    we keep around 3.{N..N+5} and we have two worthy variants.

    Plus the chore of treecleaning older packages. Not sure if it is worth it.

    That sounds like an advantage, actually. Currently, we keep older
    versions for a long time, then they suddenly disappear. All the things considered, perhaps we ought to verbosely last rite them.

    In fact, even today "emerge dev-lang/python" is probably a bad solution,
    as it will lead to a beta/rc version on an ~arch system most
    of the time.

    An alternative for freethreading support wouldn't be to install both
    from the same package python-3.14 and have the two PYTHON_TARGETS ?

    I don't understand.

    emerge =python-3.14 would install both a non-freethreading and a freethreading version and it would satisfy 3_14 and 3_14t at the same.


    But that's not how PMs work? It would install only the "newer" version,
    which would probably mean freethreading, which is not what people
    usually want.

    --
    Best regards,
    Michał Górny


    -----BEGIN PGP SIGNATURE-----

    iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcKc7wSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOlT8IAJSjduSTSKCGe74TAZFMQ/2q/cObNoBZ TyYJx3dlhLrIP/3tMGQEqqOZnc70vfiRUARWyWbFZQ+NMfIvc7bN3da3TF46n4Rp 0urQk2VNu65x2OYPd0pjZPgTbF8udJiMSz3k1rQQAZs6gWtJUiLT3EvS/SrFBGX7 lQqV/GsZ3nNf96hnKPPh7Rqoh6ULuATRDSdhqp3gF8GMs3Qb6X0m1BLgvTScCZXI fULkU/9LhFbRe4q2DfGZzXJkRyzSRsXP+mjImlQdhYRzM2vRbhKCEpWSzvE8xvmk dYWib46umryvLbqua54D9yxBfK/OCPyiBMB+pZ7JwfIj1Ro+whwriSc=
    =4UIy
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam James@21:1/5 to mgorny@gentoo.org on Sat Oct 12 15:20:01 2024
    Michał Górny <mgorny@gentoo.org> writes:

    On Sat, 2024-10-12 at 10:50 +0200, Luca Barbato wrote:
    On 12/10/24 10:12, Michał Górny wrote:
    Comments?

    I'm afraid it would lead to way too many packages and I'm not sure the
    overall experience would be an improvement.

    5 are too many?

    With your proposed solution, if an user wants to have any version of
    python what should ask to emerge?

    Can you actually imagine having a Gentoo system with no Python
    preinstalled, with an user actually needing to emerge one?

    I'll note that this happens readily with crossdev.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Barbato@21:1/5 to All on Sat Oct 12 19:40:01 2024
    On 12/10/24 15:03, Michał Górny wrote:

    emerge =python-3.14 would install both a non-freethreading and a
    freethreading version and it would satisfy 3_14 and 3_14t at the same.


    But that's not how PMs work? It would install only the "newer" version, which would probably mean freethreading, which is not what people
    usually want.

    I mean that the python-3.14 ebuild would install both versions for the
    time being. the PM does not see anything special.

    lu

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