| 1 |
Hello, all. |
| 2 |
|
| 3 |
PyPy is currently slotted in a way similar to other versions of Python. |
| 4 |
However, versioning of PyPy doesn't really fit the way CPython is |
| 5 |
versioned and the almost-per-version slotting seems unnecessary. |
| 6 |
|
| 7 |
My idea is to switch to a single slot of PyPy starting with the next |
| 8 |
version to enter gx86. That is, we would no longer have: |
| 9 |
|
| 10 |
PYTHON_COMPAT=( pypy{1_8,1_9,2_0} ... ) |
| 11 |
|
| 12 |
but instead: |
| 13 |
|
| 14 |
PYTHON_COMPAT=( pypy pypy3 ) |
| 15 |
|
| 16 |
Similarly, we'd either have dev-python/pypy with slots 2 and 3, or even |
| 17 |
separate dev-python/pypy3 with slot 0. |
| 18 |
|
| 19 |
We would also add := subslot deps to enforce package rebuilds on pypy |
| 20 |
upgrade. |
| 21 |
|
| 22 |
The existing slots could be kept alive as long as pypy2.0 is supported. |
| 23 |
|
| 24 |
|
| 25 |
Rationale: |
| 26 |
|
| 27 |
Multiple slots of PyPy are using the standard library from the same |
| 28 |
slot of CPython. Considering that slotting mostly helps prevent |
| 29 |
breakages on upgrade, I don't think we actually need to make more |
| 30 |
guarantees about PyPy than about CPython. |
| 31 |
|
| 32 |
Therefore, new versions of PyPy often cause less trouble than new |
| 33 |
versions of CPython. Testing all packages and updating PYTHON_COMPAT |
| 34 |
on each new release of PyPy seems like a overkill to me. |
| 35 |
|
| 36 |
Then, with pypy3 around, the version number appending ends up really |
| 37 |
nasty. Having just 'pypy' and 'pypy3' will simply be cleaner :). |
| 38 |
|
| 39 |
|
| 40 |
What do you think? |
| 41 |
|
| 42 |
-- |
| 43 |
Best regards, |
| 44 |
Michał Górny |
Archives