|Summary:||pypy's version is hardcoded in paths|
|Product:||[Fedora] Fedora||Reporter:||Miro Hrončok <mhroncok>|
|Component:||pypy||Assignee:||Michal Cyprian <mcyprian>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||28||CC:||aabdnn, dmalcolm, mcyprian, mhroncok, pviktori, python-sig, zbyszek|
|Fixed In Version:||pypy-5.10.0-2.fc28||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2018-04-10 22:57:47 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Miro Hrončok 2017-11-23 13:46:32 UTC
From https://bugzilla.redhat.com/show_bug.cgi?id=1316034#c15 (Anand Buddhdev) > Hello Michal, > > The core of the problem is that the pypy RPMs, for both CentOS 6 and CentOS > 7, have been incorrectly packaged from the start. Specifically, the > pypy-libs subpackage places all the files in a directory tied to the version > of pypy, like this: > > /usr/lib64/pypy-5.0.1 > > When creating a virtualenv, it gets symlinked to this directory. As a > result, ANY upgrade of pypy-libs to a new version will break any virtualenv. > > Can you guys think of a way to upgrade pypy and fix this core problem? In > other words, can you please repackage pypy-libs to place its files into: > > /usr/lib64/pypy > > This way, upgrading pypy shouldn't break any virtualenvs. I think we shall fix this for future Fedora releases. Both for pypy and pypy3. That would allow us to do minor updates on stable Fedora versions. (Note that changing this in EPEL is not very likely.)
Comment 1 Toshio Kuratomi 2017-11-23 18:26:16 UTC
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.
Comment 2 Petr Viktorin 2017-11-24 09:30:50 UTC
Is the target CPython version related to PyPy's code/bytecode/etc.?
Comment 3 Toshio Kuratomi 2017-11-24 15:40:40 UTC
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).
Comment 4 Miro Hrončok 2017-11-25 09:59:59 UTC
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.
Comment 5 Miro Hrončok 2017-11-30 11:31:28 UTC
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.
Comment 6 Michal Cyprian 2017-11-30 11:50:24 UTC
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.
Comment 7 Miro Hrončok 2017-11-30 16:11:14 UTC
(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
Comment 8 Fedora End Of Life 2018-02-20 15:33:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Comment 9 Fedora Update System 2018-04-05 11:44:43 UTC
pypy-5.10.0-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1253ab3bed
Comment 10 Fedora Update System 2018-04-06 18:54:32 UTC
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
Comment 11 Zbigniew Jędrzejewski-Szmek 2018-04-07 10:38:53 UTC
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.
Comment 12 Fedora Update System 2018-04-10 22:57:47 UTC
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.