From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E33AF158042 for ; Sat, 19 Oct 2024 15:39:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E837BE079C; Sat, 19 Oct 2024 15:39:25 +0000 (UTC) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C3570E0769 for ; Sat, 19 Oct 2024 15:39:23 +0000 (UTC) Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-71e6d988ecfso2417312b3a.0 for ; Sat, 19 Oct 2024 08:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=psc.edu; s=google; t=1729352362; x=1729957162; darn=lists.gentoo.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ePcZu5JEK/hxIc4PcHxo9VW+YkRd8jrC+unfG0SKvPs=; b=KUl2Qh0VziE6lrq9h8E0L8JaX+j+374h8BwLE8i4rYouCs767IzC6CBpyiH/VeSeG+ OYXUguSKEqjb3WpIa/oC4iCZnJNS1ob05jYREIJUIrJhNkuENhtOF0Kh0JRtsrSO6G3e NHqBP9CyRXrWprUfwFTnAQiHdt3SFO/HC4TvY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729352362; x=1729957162; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ePcZu5JEK/hxIc4PcHxo9VW+YkRd8jrC+unfG0SKvPs=; b=C2QFCf6y69g+D9+3FWKzD9F6OQygF/fKIHR2Hr1AiWLA4FjSkUNi2t/YfR+NZbz8Ji m53EZS9p5Y2zM7Nj0PwgMlG+qg4nJURvhO02TwqLM1uas/iF1rG8xNOFuGc9EiABNJiW NRuIJOaUKHEjBzfenPMjCOfCk+Pfbo/ejWK9A7dJm1keWnPP1y7HI9pILTEe2Idxt5Sj UeCBZa/u2E10/SuyYKvZjv/xelj4nVwN3lpbMQvRy6fMEb6qZVo6zwfaknho98Fr+ZeK 6tV4C5rE6aLdST98JYXfGncl+/COiLZkRb04EMBE1lErli03NCg9rfbBYlcY+zn1tLin 1fmA== X-Gm-Message-State: AOJu0Yy8ollzQGrJdbdZMKRWSAE1e1s0XHXHGbFq14Ou33K+CUsmmJ4L gjaboXECMeiEF0zpkzMJ6nh061PWOIaQ62Osx4nwn6WotKdglFdHnUOqql/n/3eAtxlIxP0h8r9 fsogaRSTi31k53gx/6yjRvbCJ10LdKe6UGq0/lRMxAhbSKeRZ X-Google-Smtp-Source: AGHT+IF+IYIO4NImFel8XIuJLfq1Sff9IpRl4mpmFp68UkDzEN8IuAN57MhshvH+oNwvxINawaJxAd6TA9JHW9rFaHQ= X-Received: by 2002:a05:6a00:2441:b0:71e:4dc5:259e with SMTP id d2e1a72fcca58-71ea32cffd3mr8015466b3a.17.1729352362309; Sat, 19 Oct 2024 08:39:22 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: In-Reply-To: From: Mitchell Dorrell Date: Sat, 19 Oct 2024 11:39:12 -0400 Message-ID: Subject: Re: [gentoo-dev] Slotting PyPy To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000003f587c0624d639e0" X-Archives-Salt: 1360d11a-31ba-4654-894b-810acbb7441d X-Archives-Hash: 65e85006b385911f9d33eef8ea033a0b --0000000000003f587c0624d639e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 17, 2024, 08:12 Micha=C5=82 G=C3=B3rny wrot= e: > PyPy has basically two versions: > > >>>> sys.version_info > sys.version_info(major=3D3, minor=3D10, micro=3D14, releaselevel=3D'final= ', > serial=3D0) > >>>> sys.pypy_version_info > sys.pypy_version_info(major=3D7, minor=3D3, micro=3D17, releaselevel=3D'f= inal', > serial=3D0) > > The former indicates the CPython version it is compatible with, > and the stdlib version from CPython it used. The latter is the actual > PyPy release. > > PyPy is doing synchronous releases for all Python versions it supports at > the time, with PyPy release matching between them. For example, 7.3.16 > release involved the following tarballs: > > pypy3.10-v7.3.16-src.tar.bz2 > pypy3.9-v7.3.16-src.tar.bz2 > pypy2.7-v7.3.16-src.tar.bz2 > This sounds like another potential application of the "VARIANTS" concept I suggested last week: https://marc.info/?l=3Dgentoo-dev&m=3D172877401607588 In short, some software has multiple variants of each version which may need to be installed simultaneously, without the older/newer relationship that slots imply. (There could be other benefits, too, irrelevant to this discussion.) Perhaps I should implement this as a proof-of-concept and start a separate thread to discuss it. For the relatively short transitions when two PyPy 3.x versions were > released, we combined revisions and subslots, e.g.: > > dev-python/pypy3-7.3.16:0/pypy39-... > dev-python/pypy3-7.3.16-r100:0/pypy310-... > > would correspond to, respectively: > > pypy3.9-v7.3.16-src.tar.bz2 > pypy3.10-v7.3.16-src.tar.bz2 > > The eclasses would depend on 'dev-python/pypy3:=3D' to bind to a specific > subslot, and soon afterwards we'd just be providing the next PyPy 3.x > versions without the older. > > Then, as we decided to keep older CPython versions around without eclass > support (3.8 and 3.9), it started to make sense to also keep old PyPy 3.x > versions around -- also without eclass support. So I've split the packag= es > even further, into: > > dev-python/pypy3_9-7.3.16 > dev-python/pypy3_10-7.3.16 > > that correspond to, respectively: > > pypy3.9-v7.3.16-src.tar.bz2 > pypy3.10-v7.3.16-src.tar.bz2 > > And dev-python/pypy3 remained as a subslotted virtual that would pull > whichever PyPy 3.x version we support at the time. > > > Slotting again > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A possible goal for the future would be to recombine all these packages > into one, e.g.: > > dev-lang/pypy-2.7.7.3.16:pypy27/... > dev-lang/pypy-3.9.7.3.16:pypy39/... > dev-lang/pypy-3.10.7.3.16:pypy310/... > > corresponding to: > > pypy2.7-v7.3.16-src.tar.bz2 > pypy3.9-v7.3.16-src.tar.bz2 > pypy3.10-v7.3.16-src.tar.bz2 > > So the PV would combine slot and release version, slot would indicate PyP= y > 3.x slot and subslot would indicate the ABI (changes rarely). > Previously, you "split the packages even further", but now you're suggesting to "recombine all these packages into one". What was the original reason for splitting the packages, and what has changed since then= ? I don't understand enough of the Python and PyPy infrastructure to support or object to either approach. I generally think it's more elegant to have a single package for a single codebase/project, but the practical concerns are more important. - Mitchell Dorrell > --0000000000003f587c0624d639e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 17, 2024, 08:12 Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
PyPy has basically two versions:

>>>> sys.version_info
sys.version_info(major=3D3, minor=3D10, micro=3D14, releaselevel=3D'fin= al', serial=3D0)
>>>> sys.pypy_version_info
sys.pypy_version_info(major=3D7, minor=3D3, micro=3D17, releaselevel=3D'= ;final', serial=3D0)

The former indicates the CPython version it is compatible with,
and the stdlib version from CPython it used.=C2=A0 The latter is the actual= PyPy release.

PyPy is doing synchronous releases for all Python versions it supports at t= he time, with PyPy release matching between them.=C2=A0 For example, 7.3.16= release involved the following tarballs:

=C2=A0 pypy3.10-v7.3.16-src.tar.bz2
=C2=A0 pypy3.9-v7.3.16-src.tar.bz2
=C2=A0 pypy2.7-v7.3.16-src.tar.bz2

This sounds lik= e another potential application of the "VARIANTS" concept I sugge= sted last week:
In short, some software has multiple = variants of each version which may need to be installed simultaneously, wit= hout the older/newer relationship that slots imply. (There could be other b= enefits, too, irrelevant to this discussion.) Perhaps I should implement th= is as a proof-of-concept and start a separate thread to discuss it.

For the relatively short transitions when = two PyPy 3.x versions were released, we combined revisions and subslots, e.= g.:

=C2=A0 dev-python/pypy3-7.3.16:0/pypy39-...
=C2=A0 dev-python/pypy3-7.3.16-r100:0/pypy310-...

would correspond to, respectively:

=C2=A0 pypy3.9-v7.3.16-src.tar.bz2
=C2=A0 pypy3.10-v7.3.16-src.tar.bz2

The eclasses would depend on 'dev-python/pypy3:=3D' to bind to a sp= ecific subslot, and soon afterwards we'd just be providing the next PyP= y 3.x versions without the older.

Then, as we decided to keep older CPython versions around without eclass su= pport (3.8 and 3.9), it started to make sense to also keep old PyPy 3.x ver= sions around -- also without eclass support.=C2=A0 So I've split the pa= ckages even further, into:

=C2=A0 dev-python/pypy3_9-7.3.16
=C2=A0 dev-python/pypy3_10-7.3.16

that correspond to, respectively:

=C2=A0 pypy3.9-v7.3.16-src.tar.bz2
=C2=A0 pypy3.10-v7.3.16-src.tar.bz2

And dev-python/pypy3 remained as a subslotted virtual that would pull which= ever PyPy 3.x version we support at the time.


Slotting again
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A possible goal for the future would be to recombine all these packages int= o one, e.g.:

=C2=A0 dev-lang/pypy-2.7.7.3.16:pypy27/...
=C2=A0 dev-lang/pypy-3.9.7.3.16:pypy39/...
=C2=A0 dev-lang/pypy-3.10.7.3.16:pypy310/...

corresponding to:

=C2=A0 pypy2.7-v7.3.16-src.tar.bz2
=C2=A0 pypy3.9-v7.3.16-src.tar.bz2
=C2=A0 pypy3.10-v7.3.16-src.tar.bz2

So the PV would combine slot and release version, slot would indicate PyPy = 3.x slot and subslot would indicate the ABI (changes rarely).

Previously, yo= u "split the packages even further", but now you're suggestin= g to "recombine all these packages into one". What was the origin= al reason for splitting the packages, and what has changed since then?

I don't understand enoug= h of the Python and PyPy infrastructure to support or object to either appr= oach. I generally think it's more elegant to have a single package for = a single codebase/project, but the practical concerns are more important.

- Mitchell Dorrell
<= div dir=3D"auto">
--0000000000003f587c0624d639e0--