Re: [gentoo-dev] Slotting PyPy

[Mitchell Dorrell <mwd@psc.edu>]

[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]

On Thu, Oct 17, 2024, 08:12 Michał Górny <mgorny@gentoo.org> wrote:

> PyPy has basically two versions:
>
> >>>> sys.version_info
> sys.version_info(major=3, minor=10, micro=14, releaselevel='final',
> serial=0)
> >>>> sys.pypy_version_info
> sys.pypy_version_info(major=7, minor=3, micro=17, releaselevel='final',
> serial=0)
>
> 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=gentoo-dev&m=172877401607588
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:=' 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
> ==============
>
> 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).
>

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

>

[-- Attachment #2: Type: text/html, Size: 4673 bytes --]