[gentoo-python] RFC: dropping slots on PyPy

[gentoo-python] RFC: dropping slots on PyPy

[Michał Górny]

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

Hello, all.

PyPy is currently slotted in a way similar to other versions of Python.
However, versioning of PyPy doesn't really fit the way CPython is
versioned and the almost-per-version slotting seems unnecessary.

My idea is to switch to a single slot of PyPy starting with the next
version to enter gx86. That is, we would no longer have:

  PYTHON_COMPAT=( pypy{1_8,1_9,2_0} ... )

but instead:

  PYTHON_COMPAT=( pypy pypy3 )

Similarly, we'd either have dev-python/pypy with slots 2 and 3, or even
separate dev-python/pypy3 with slot 0.

We would also add := subslot deps to enforce package rebuilds on pypy
upgrade.

The existing slots could be kept alive as long as pypy2.0 is supported.


Rationale:

Multiple slots of PyPy are using the standard library from the same
slot of CPython. Considering that slotting mostly helps prevent
breakages on upgrade, I don't think we actually need to make more
guarantees about PyPy than about CPython.

Therefore, new versions of PyPy often cause less trouble than new
versions of CPython. Testing all packages and updating PYTHON_COMPAT
on each new release of PyPy seems like a overkill to me.

Then, with pypy3 around, the version number appending ends up really
nasty. Having just 'pypy' and 'pypy3' will simply be cleaner :).


What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-python] RFC: dropping slots on PyPy

[Mike Gilbert]

On Mon, Jan 13, 2014 at 11:57 AM, Michał Górny <mgorny@gentoo.org> wrote:
> PyPy is currently slotted in a way similar to other versions of Python.
> However, versioning of PyPy doesn't really fit the way CPython is
> versioned and the almost-per-version slotting seems unnecessary.
>
> My idea is to switch to a single slot of PyPy starting with the next
> version to enter gx86.
> What do you think?
>

No objection from me, though I don't really use PyPy for anything.

Personally, I wouldn't mind consolidating CPython the same way, but
that's a separate topic.

[gentoo-python] Re: RFC: dropping slots on PyPy

[Marien Zwart]

On Tue, Jan 14, 2014 at 5:45 AM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> On Mon, Jan 13, 2014 at 5:57 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > What do you think?
>
> I'm not really sure. Yes, PyPy versioning hasn't caused much pain, but
> part of that is because pypy3 usage is very limited at this point, and
> PyPy has only ever targeted 2.7. So I'd argue that PyPy comes with
> similar problems as CPython releases, and for the same reasons (after
> all, they're targeting the same language and the same stdlib!), we
> just haven't run into them yet because there are fewer users and PyPy
> has only recently started getting more diversity in supported
> language/stdlib implementations.

Hmm, naming PyPy binaries came up before, but it looks like slotting
didn't. I wonder why I'm feeling deja vu here.

I think I mostly agree with Dirkjan: slotting may provide some
benefits for Python 3 even if it doesn't do much for Python 2. And I'd
probably slot by the CPython version it targets.

That'll just get moderately confusing if PyPy versioning seriously
mismatches CPython versioning: do you stick just the PyPy version
number in paths/filenames, just the slot, or both?

On the other hand (at least in the short term) running an older PyPy
isn't something I'd expect a lot of people to do: running the latest
and greatest is usually beneficial, not just for features but also for
better performance and fewer bugs. Chances are most users will either
fix their code to work with latest PyPy, or run it under CPython for
compatibility. That seems like an argument not to keep PyPy slotting
if it's awkward to implement.

My 2 cents, etc...
-- 

Marien Zwart (marienz)

Re: [gentoo-python] Re: RFC: dropping slots on PyPy

[Michał Górny]

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

Dnia 2014-01-14, o godz. 14:27:03
Marien Zwart <marienz@gentoo.org> napisał(a):

> On the other hand (at least in the short term) running an older PyPy
> isn't something I'd expect a lot of people to do: running the latest
> and greatest is usually beneficial, not just for features but also for
> better performance and fewer bugs. Chances are most users will either
> fix their code to work with latest PyPy, or run it under CPython for
> compatibility. That seems like an argument not to keep PyPy slotting
> if it's awkward to implement.

Oh, this reminds me of yet another argument. We're basically supporting
only one version of PyPy at a time. This makes the current workflow
like:

1. add new slot,

2. add PYTHON_COMPAT for new slot,

3. remove old slot.

So the two versions are really supported for a short time. I think we
may instead use the following work flow:

1. add new PyPy masked,

2. test packages,

3. unmask new PyPy :).

This would also mean that we'd be able to avoid removing old versions
of PyPy as fast as we do now.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]