Bug 1516885

We do need to keep some sort of version numbering so that people don't try to use incompatible versions of pypy with their code/bytecode/etc.  It looks like pypy knows the versions of CPython that they're targeting for compatibility (For instance, the release notes here: http://doc.pypy.org/en/latest/release-v5.9.0.html says that pypy-5.9 targets CPython-2.7 and CPython-3.5) so perhaps we could use those version numbers just as CPython has those numbers in their filesystem paths.

Is the target CPython version related to PyPy's code/bytecode/etc.?

I've been trying to figure that out without success.  The documentation makes clear that the byte code in pypy is not the same as the byte code in the CPython reference implementation but does not make clear any guarantees on the part of pypy as to when they would make changes to it.

Byte code is also not the only difference that will affect whether the pypy release is backwards compatible with previous versions.  Changes in the language itself (adding async and await as keywords, for instance) and even changes in the standard library also have to be taken into account.

I think someone's going to have to take this question upstream to work out a solution.  Possibilities include upstream's version scheme assigning a backwards compatible guarantee to a certain number in their version string (for instance, pypy3-4 vs pypy3-5) or us including both the CPython target version and a portion of the pypy version (ie: pypy3.6-4, pypy3.6-5).

BTW this is what a filename of pypy3 5.9.0 bytecode looks like:

/usr/lib64/pypy3-5.9.0/lib_pypy/__pycache__/audioop.pypy3-59.opt-1.pyc

It kinda give's me an impression that pypy3-59 is the identifier. I.e. that from 5.9.0, the 5.9 matters.

This is how my so files look like on pypy 5.8.0:

/usr/lib64/pypy-5.8.0/lib_pypy/_audioop_cffi.pypy-41.so

Apparently, I have no pyc file at all (a bug maybe?), but since this is python 2, the version would not be there unless pypy does that differently.

On Debian there is not PyPy version at all in the paths:
['',
 '/usr/lib/pypy/lib_pypy/__extensions__',
 '/usr/lib/pypy/lib_pypy',
 '/usr/lib/pypy/lib-python/2.7',
 '/usr/lib/pypy/lib-python/2.7/lib-tk',
 '/usr/lib/pypy/lib-python/2.7/plat-linux2',
 '/usr/local/lib/pypy2.7/dist-packages',
 '/usr/lib/pypy/dist-packages']

PyPy version in the path is not an upstream thing, it was packaged for Fedora this way. We can ask upstream if there is some relation between PyPy releases and compatibility. It doesn't seem to be documented anywhere as Toshio Kuratomi pointed out.

(In reply to Miro Hrončok from comment #5)
> Apparently, I have no pyc file at all (a bug maybe?)

https://bugzilla.redhat.com/show_bug.cgi?id=1519238

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

pypy-5.10.0-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1253ab3bed

pypy-5.10.0-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1253ab3bed

https://src.fedoraproject.org/rpms/pypy/c/6eff80aa8f282081264bd6ffe51bd1c0a4fbcf64?branch=master changes the path from pypy-5.10.0 to pypy-5.10. This is still different then what upstream does and what the OP requested. Unfortunately the commit does not contain any justification why this particular choice was made. I would like to know *why* this was decided this way.

pypy-5.10.0-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.