Missing Linux cp311 manylinux wheel for PyMuPDF 1.26.1

[akshit0201]

Description of the bug

PyMuPDF 1.26.1 (released 2025-06-12) is published on PyPI solely as an sdist.
Previous versions (e.g. 1.25.x, 1.26.0) included manylinux wheels, so pip install PyMuPDF worked on minimal images such as AWS Lambda’s public.ecr.aws/lambda/python:3.11. With 1.26.1 pip falls back to building from source and fails because the container has no compiler tool-chain.

How to reproduce the bug

Run these commands

docker run --rm -it --platform linux/amd64 public.ecr.aws/lambda/python:3.11 bash
pip install --no-cache-dir PyMuPDF==1.26.1

Actual result

Collecting PyMuPDF==1.26.1
  Downloading pymupdf-1.26.1.tar.gz (75.9 MB)
  Preparing metadata (pyproject.toml): started
  Preparing metadata (pyproject.toml): finished with status 'error'
…
/bin/sh: cc: command not found
subprocess.CalledProcessError: Command 'cc --version' returned non-zero exit status 127.
error: metadata-generation-failed

Expected result

PyMuPDF-1.26.1-cp311-cp311-manylinux_2_17_x86_64.whl

PyMuPDF version

1.26.1

Operating system

Linux

Python version

3.11

[JorjMcKie]

There is this wheel for Linux systems: pymupdf-1.26.1-cp39-abi3-manylinux_2_28_x86_64.whl.
If your Python (especially pip) is current enough it will find and install it.

[akshit0201]

Is there any for Linux 2 (glibc 2.26) ?

[JorjMcKie]

Here is a list of available installation files: https://pypi.org/project/PyMuPDF/#files

[jc-louis]

This is a major regression preventing us from using PyMuPDF in standard docker images

[julian-smith-artifex-com]

Just to expand on what @JorjMcKie has already said, manylinux_2_17 (also known as manylinux2014) is now past end-of-life - see https://cibuildwheel.pypa.io/en/stable/cpp_standards/#manylinux2014-and-c20 - so the standard Python packaging systems (in this case cibuildwheel) no longer generate such wheels.

We don't have much control over this. It might be possible to persuade cibuildwheel/Github to generate these obsolete wheels in the short term, but we don't know how to do this, and it would significantly complicate our build/release infrastructure. We do not think this is the correct solution to the problem of a docker image that uses an old glibc release from 2017 (8 years ago) that is explicitly not supported by Python any more.

I think your options are:

1. Build PyMuPDF locally by installing build tools such as gcc into your container.
   The build itself is pretty reliable and automated, but this will require that some required build-time python packages (such as libclang) also support glibc-2.26, which is probably the case at the moment, but will almost certainly fail at some point in the future as the Python world moves on to glibc-2.28.
2. Upgrade to a newer docker image that uses glibc-2.28 or later.

I hope that makes sense.

[mayurankv]

I'm using the public.ecr.aws/docker/library/python:3.12.10-slim image and I get the same error. I'd feel quite surprised were that docker image to be out of date? Or am I wrong/misunderstanding something?

[JorjMcKie]

I'm using the public.ecr.aws/docker/library/python:3.12.10-slim image and I get the same error. I'd feel quite surprised were that docker image to be out of date? Or am I wrong/misunderstanding something?

You got it right.