From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-102659-garchives=archives.gentoo.org@lists.gentoo.org> 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 976CA158042 for <garchives@archives.gentoo.org>; Thu, 17 Oct 2024 12:12:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4EF75E07EA; Thu, 17 Oct 2024 12:12:07 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 pigeon.gentoo.org (Postfix) with ESMTPS id 7BF74E07D0 for <gentoo-dev@lists.gentoo.org>; Thu, 17 Oct 2024 12:12:06 +0000 (UTC) Message-ID: <c5725e83a0aa69054cd9edb7a8d2ada7ab8e537c.camel@gentoo.org> Subject: [gentoo-dev] Slotting PyPy From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= <mgorny@gentoo.org> To: gentoo-dev@lists.gentoo.org Date: Thu, 17 Oct 2024 14:12:00 +0200 Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-vhyv/TDyM/eAKqFFlhwv" User-Agent: Evolution 3.52.4 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> 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 X-Archives-Salt: dbe4a1b0-8d5b-4b40-b957-368fbb545d11 X-Archives-Hash: a7a068d86ba160d5e330f0ea8dfb6da5 --=-vhyv/TDyM/eAKqFFlhwv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Given that you've expressed your preference for dev-lang/python remaining slotted, I'd like to open another can of worms: should we slot PyPy consistently with it? Some history and then my ideas below. PyPy versioning =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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'fin= al', 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 Nowadays PyPy2.7 and PyPy3.10 are supported and released, and there should be a PyPy3.11 release soon. History and overview of Gentoo packages =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Initially, we had just PyPy 2.x packaged, as dev-python/pypy, e.g.: dev-python/pypy-7.3.17 corresponds to: pypy2.7-v7.3.17-src.tar.bz2 Then we added PyPy 3.x as a dev-python/pypy3 package, e.g.: dev-python/pypy3-7.3.16 would correspond to: pypy3.10-v7.3.16-src.tar.bz2 We have decided to support only a single PyPy 3.x slot, for two reasons: 1) PyPy is quite experimental, and 2) upstream is usually far behind CPython on releases (PyPy is at 3.10 still, while CPython just released 3.13). 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 packages 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 PyPy 3.x slot and subslot would indicate the ABI (changes rarely). The ebuilds could now depend e.g. on: >=3Ddev-lang/pypy-3.10:=3D This would ensure that only slots newer than 3.10 are acceptable, and that packages are rebuilt (as they are right now) once we introduce 3.11 slot. Then, after the transitional period we'd update it to: >=3Ddev-lang/pypy-3.11:=3D and so on. Backwards compatibility and transition =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For the time being, we'd have to maintain dev-python/pypy3 as a "virtual" for compatibility. The eclasses would be updated, so that newly built packages depend on and bind to the slots of the new package. Once PyPy3.11 is released, dev-python/pypy3 would gain a new subslot, and the :=3D deps will be triggering the rebuild. At the same time, the rebuild will result in the packages updating to depend on the new package. Some time after this transition, we'd be able to last rite dev-python/pypy3. Summary =3D=3D=3D=3D=3D=3D=3D So the rough idea is that we'd be replacing dev-python/pypy, dev- python/pypy3, dev-python/pypy3_9, dev-python/pypy3_10 with a single slotted package. At least the second package would have to preserved for some time, for backwards compatibility; the others are less significant since they are not used in eclass-generated dependencies. I suppose we'd also be then aiming to combine dev-python/pypy*-exe dev-python/pypy*-exe-bin to some degree, but that's a minor point, since they are implementation details. WDYT? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-vhyv/TDyM/eAKqFFlhwv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmcQ/xASHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQO96MH/iqYbrangTYSJAXaxLL69XIU6NMfUOHe BpAbyKx2EyQ2ES2tB4s0jg15ZruatvvhryENUlTI+dfDlbmnJxJjydZ1t+07uZK/ g3/9Tm5cL/4sNZaQaan1rwgpr6v9eoSX416e/KJmYfFJ+EXzVevXbv2LIIbCwvuK lPZfW5hoQBWdgBv3sutOINTT96A3FD8MZTkoTuMNnzFH3elQ1duiaI2V1kH0HrZ4 8g2/FJ4sO33stc9ddKIFlZvcNWxYsUzkjQCzMAAxMvhLk0BYo8Cy6pV0yKHDb8Cz 6y7iEnBKyGTDBoSNgZO9LoB62ATmryaS1xSDqYfZ7kU+DQYa6rlOP1I= =iKbi -----END PGP SIGNATURE----- --=-vhyv/TDyM/eAKqFFlhwv--