PyPy 7.3.1 was released April 10, 2020. It would be great for the Docker image to be updated for this.

The CPython images provide rc and rc-slim tags to refer to whatever is the current development version, in addition to 3 / latest. Would it be possible to have those for PyPy?

PyPy 5.7 is released, supporting Python 2.7 and Python 3.5. It would be great to get this added.

It appears that some of the tags are missing the linux/s390x platform the one that I noticed was 3-slim.

Has the s390x platform been deprecated?

When trying to use uwsgi to start a django-project I get the Error:

unable to load pypy library: libpypy-c.so: cannot open shared object file: No such file or directory

after a short goolge search i find it is related to the pypy-libs package, or in the py3 case propably the pypy3-libs package, which is not preinstalled with the container and the path for it is not deposited for later installation.

It would be awesome to have PyPy images for Docker on ARM: Hypriot http://blog.hypriot.com/

This includes a fix that is important for lxml users.

Hello, I see that you've updated to the new 7.3.12 release of pypy. That release also contains a python 3.10 interpreter Would it be possible to add this to the official images (there will be no more releases of 3.8) ?

Happy to open a PR if that helps.

https://gitlab.com/KOLANICH1/Chassis.py/-/jobs/83348020

I previoulsy worked with an unofficial alpine image (Pypy 7.3.0) to package a uwsgi application, and decided to switch to the official (Pypy 7.3.1) image.

I had a problem when switching because of 61bb082 which changes the location of all files inside the image.

Updating the uwsgi configuration to the new paths did not help.

It may be a problem inside uwsgi (especially since pypy3 support is rather fragile), however it could also be a regression so I wanted to report here.

The only information I got about the problem looks like this (stracing the uwsgi process):

stat("/opt/pypy//lib_pypy", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/opt/pypy/lib_pypy/x", 0x55b239982120) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/pypy/lib_pypy/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/opt/pypy/lib_pypy/python36.zip", 0x55b239982120) = -1 ENOENT (No such file or directory)
stat("/opt/pypy/lib_pypy/lib-python/3", 0x55b239982120) = -1 ENOENT (No such file or directory)
lstat("/opt/pypy/lib_pypy", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/opt/pypy/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/opt/pypy/python36.zip", 0x55b239982120) = -1 ENOENT (No such file or directory)
stat("/opt/pypy/lib-python/3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/opt/pypy/lib_pypy", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(2, "debug: OperationError:\n", 23debug: OperationError:
) = 23
write(2, "debug:  operror-type: ModuleNotF"..., 42debug:  operror-type: ModuleNotFoundError
) = 42
write(2, "debug:  operror-value: No module"..., 44debug:  operror-value: No module named 'os'
) = 44
write(2, "unable to set pypy home to \"/opt"..., 40unable to set pypy home to "/opt/pypy/"
) = 40
getpid()                                = 1041
exit_group(1)                           = ?
+++ exited with 1 +++

Do not hesitate to close this if irrelevant.

In the Dockerfile, the intention seems to be to override the system python

This isn't the case though:

$ docker run --rm pypy:3 python --version
Python 2.7.9

I "fixed" it in my inheriting Dockerfile with

RUN if command -v pypy3; then ln -s $(command -v pypy3) /usr/local/bin/python; fi

but that seems suboptimal.

The PyPy team is no longer releasing PyPy3.7 and would prefer people use PyPy3.8 by default. Is there a way to reconfigure the pypy:3 tag to point to PyPy3.8? See also https://foss.heptapod.net/pypy/pypy/-/issues/3606#note_184761

uuid.uuid1() will return strange uuids after 1095 generations.

step 1: create docker container
$ sudo docker run -d -it --name pypyt-test pypy:2 /bin/bash

step 2: sample code
root@1e65a430de73:/# cat /tmp/test.py
import sys, time, uuid
N = int(sys.argv[1])
t = time.time()
for x in xrange(N):
print uuid.uuid1()

step 3:
root@1e65a430de73:/# pypy /tmp/test.py 1099
...
02d62faa-9cb0-11e5-96db-0242ac110016
02d63270-9cb0-11e5-96db-0242ac110016
02d6359a-9cb0-11e5-96db-0242ac110016
02d6d5e0-9cb0-11e5-96db-0242ac110016
02d860d6-9cb0-11e5-96db-0242ac110016
01000000-0000-0000-0000-000000000000 - line num 1095
08c9287a-3c7f-0000-70b4-287a3c7f0000
88f5747a-3c7f-0000-2024-5a7a3c7f0000
ffffffff-ffff-ffff-2805-000000000000

In (at least) pypy:3.7, /usr/bin/python refers to python 2.7.

Aside from the fact 2.7 is deprecated and EOL, can /usr/bin/python inside this image please refer to pypy instead? (so that any python commands will automatically use pypy)

pypy get-pip.py --disable-pip-version-check --no-cache-dir pip==18.1
Double requirement given: pip (already in pip==18.1, name='pip')

The solution is to simply remove the section where pip gets installed

Jessie is marked as obsolete - https://www.debian.org/releases/.

It does pass, but we should fix the InsecurePlatformWarning.

testing pypy:2-2.5.1-slim
    'utc' [1/6]...passed
    'cve-2014--shellshock' [2/6]...passed
    'python-hy' [3/6]...passed
    'python-pip-requests-ssl' [4/6].../usr/local/site-packages/requests/packages/urllib3/util/ssl_.py:79: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
/usr/local/site-packages/requests/packages/urllib3/util/ssl_.py:79: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
passed
console

pypy 5.3 has been out for a little while now, would be nice to get a version bump here as well

Thank you!

I want to build this image on arm64 but I don't find some file to support arm64 on https://bitbucket.org/pypy/pypy/downloads/ , So I want to know this image whether or not to support arm64

This breaks other parts of the standard library.

It broke at some point in the last week.

$ docker run --rm -it pypy:3
Python 3.6.12 (db1e853f94de, Nov 18 2020, 09:49:19)
[PyPy 7.3.3 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> import crypt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/pypy/lib-python/3/crypt.py", line 3, in <module>
    import _crypt
  File "/opt/pypy/lib_pypy/_crypt/__init__.py", line 7, in <module>
    import thread
ModuleNotFoundError: No module named 'thread'

Since the twitter announcement, I am trying to pull the new pypy 7.0 image.
But if I do:

docker pull pypy:latest

the running the container, I always get:

Python 3.5.3 (fdd60ed87e94, Apr 24 2018, 06:10:04)
[PyPy 6.0.0 with GCC 6.2.0 20160901] on linux

even if the image results updated less than 2 hours ago.
Why?

I'm using PyPy 3.8. When invoking /opt/pypy/lib/pypy3.8/cgi.py I get:

$ /opt/pypy/lib/pypy3.8/cgi.py
bash: /opt/pypy/lib/pypy3.8/cgi.py: /usr/local/bin/python: bad interpreter: No such file or directory

This is because cgi.py says:

#! /usr/local/bin/python

# NOTE: the above "/usr/local/bin/python" is NOT a mistake.  It is
# intentionally NOT "/usr/bin/env python".  On many systems
# (e.g. Solaris), /usr/local/bin is not in $PATH as passed to CGI
# scripts, and /usr/local/bin is the default directory where Python is
# installed, so /usr/bin/env would be unable to find python.  Granted,
# binary installations by Linux vendors often install Python in
# /usr/bin.  So let those vendors patch cgi.py to match their choice
# of installation.

I believe the shebang should be replaced with /usr/bin/env python in this image.

I run under docker image

apt-get update
&& apt-get install -y build-essential
libjpeg-dev gettext zlib1g-dev git
libmariadb-dev

and return many truncated lib. as:

ldconfig: file /usr/local/lib/libexpat.so.1.5.2 is truncated

ldconfig: file /usr/local/lib/libffi.so.6 is truncated

ldconfig: file /usr/local/lib/libffi.so.6.0.4 is truncated

ldconfig: file /usr/local/lib/libgdbm.so.2 is truncated
.....

It would be nice to have image versions based on Alpine Linux, similar to what CPython provides ...

Example:

$ docker run --rm -it pypy:3.6-7.3.0
Python 3.6.9 (1608da62bfc7, Dec 23 2019, 10:50:04)
[PyPy 7.3.0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> import lzma
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib-python/3/lzma.py", line 27, in <module>
    from _lzma import *
  File "/usr/local/lib_pypy/_lzma.py", line 15, in <module>
    from _lzma_cffi import ffi, lib as m
ImportError: /usr/local/lib_pypy/_lzma_cffi.pypy36-pp73-x86_64-linux-gnu.so: undefined symbol: lzma_index_stream_padding

Oddly, 2.7 was bumped to pypy 7.3.13 two weeks ago, but 3.9 & 3.10 were left at 7.3.12. Since 7.3.13 includes security fixes and speed-ups, both 3.9 and 3.10 should be upgraded, too.

It seems that recent builds of the pypy docker image have used SQLite 3.7.17 from 2013. SQLite 3.8 was released in August 2013.

I don't think this is deliberate, since the pypy image used to have a more recent SQLite library and this recently changed.

In my case, I am running this code:

db = sqlite3.connect('')
db.execute('''PRAGMA application_id=0x54677474;''')

and today this started raising _sqlite3.OperationalError: unrecognized token: "0x54677474". Support for hexadecimal integers was added to SQLite version 3.8.6 (2014-08-15), so pypy is really the only place where this doesn't work.

Steps to reproduce:

docker run pypy:3 pypy3 -c "print(\"okay\")"

Results in:

pypy3: error while loading shared libraries: libpypy3-c.so: cannot open shared object file: No such file or directory

This issue is initially reported to Poetry, but after digging up a bit, it turns out it's a PyPy issue. After wrongly reporting it in the PyPy repo, here we are 👯.

Trying to install Poetry in the latest images for PyPy 3.9 and 3.10 fails with the following error:

/root/.local/share/pypoetry/venv/bin/python: error while loading shared libraries: libffi.so.6: cannot open shared object file: No such file or directory

To discard Poetry as the source of the problem, here's a reproducer not involving Poetry:

FROM pypy:3.9-slim
RUN python3 -c 'import venv; builder = venv.EnvBuilder(); builder.create("/tmp/foo")'
RUN /tmp/foo/bin/python3

Alternatively:

The system has libffi v7 installed, while for whatever reason, Python is trying to use v6. This seems to indicate that it has been built incorrectly. This situation doesn't happen on the previous version of said images, namely pypy:3.9-7.3.12-slim and pypy:3.10-7.3.12-slim.

FROM pypy:3
ENV PYTHONUNBUFFERED 1
RUN mkdir /code
WORKDIR /code

ADD docker/sources.list /etc/apt/

RUN apt-get update && apt-get install -y gettext
RUN apt-get install -y ffmpeg
RUN apt-get install -y qpdf

ADD requirements.txt /code/

RUN pip install --no-cache-dir -r requirements.txt \

-i http://mirrors.aliyun.com/pypi/simple/ \

--trusted-host mirrors.aliyun.com

RUN pip install --no-cache-dir -r requirements.txt
I replace python:3.6.12 by pypy:3,but when pip install pikepdf, i get an error:

creating build/temp.linux-x86_64-3.6/src/qpdf
  gcc -pthread -DNDEBUG -O2 -fPIC -DVERSION_INFO="1.19.3" -I/tmp/pip-build-env-uqjtm46z/overlay/site-packages/pybind11/include -I/opt/pypy/include -c src/qpdf/annotation.cpp -o build/temp.linux-x86_64-3.6/src/qpdf/annotation.o -std=c++14 -fvisibility=hidden
  src/qpdf/annotation.cpp:11:10: fatal error: qpdf/Constants.h: No such file or directory
   #include <qpdf/Constants.h>
            ^~~~~~~~~~~~~~~~~~
  compilation terminated.
  error: command 'gcc' failed with exit status 1
  ----------------------------------------
  ERROR: Failed building wheel for pikepdf

I don't know what's the different between pip in python3 and pip in pypy, could you give me some suggestion?

It would be great if a docker image for pypy-2.7 is provided based on a Debian release newer than Jessie.

Some libs in python from the latest cpython are compatible with the older releases. Some libs crash because of old stdlib libs, I have to fix it using cURL. I guess we should just find out what libs are compatible (download them all and run unit tests, if the tests fail - downgrade the lib) and use them.

After trying to run e.g. podman run -it pypy:3.9 at a Raspberry Pi running Ubuntu 20.04, the following errors are popping up.

podman run pypy:3.9
✔ docker.io/library/pypy:3.9
Trying to pull docker.io/library/pypy:3.9...
Error: choosing an image from manifest list docker://pypy:3.9: no image found in manifest list for architecture arm64, variant "v8", OS linux

At least, the tags at Dockerhub are indicating that there should be an arm64 build.

#61 managed to break our images in subtle ways with issues at runtime (rather than install) - I'm unsure how to upstream this as the exact issue is hard to pin down (see below image).

The fix was to revert back to the python3.7 version of setuptools. This should be the default, rather than supporting pypy 2.7 by using setuptools 44.x in the 3.7 image.