Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1516885 - pypy's version is hardcoded in paths
Summary: pypy's version is hardcoded in paths
Alias: None
Product: Fedora
Classification: Fedora
Component: pypy
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Michal Cyprian
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-23 13:46 UTC by Miro Hrončok
Modified: 2018-04-10 22:57 UTC (History)
7 users (show)

Fixed In Version: pypy-5.10.0-2.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-04-10 22:57:47 UTC

Attachments (Terms of Use)

Description Miro Hrončok 2017-11-23 13:46:32 UTC

(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: 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:


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:


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:

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?)

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.

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 for
instructions on how to install test updates.
You can provide feedback for this update here:

Comment 11 Zbigniew Jędrzejewski-Szmek 2018-04-07 10:38:53 UTC 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.

Note You need to log in before you can comment on or make changes to this bug.