Linux wheel platform tag "manylinux2010" requires pip 19.0 or greater

[cbm755]

I'm on an Ubuntu 18.04 VM using Python 3.6.

Looks a bit like a dupe of #358 but my understanding from https://pypi.org/project/PyMuPDF/ is that MuPDF is included in a wheel.

Again, apologies if I've misunderstood: perhaps the new install procedure is that everyone needs to get MuPDF manually!?

$ pip install --user pymupdf
Collecting pymupdf
  Using cached https://files.pythonhosted.org/packages/99/4c/5f1506fed9d6dc1cb58b11e7d4e773fa11da99bd3dbe77b38cc09d130643/PyMuPDF-1.16.7.tar.gz
Building wheels for collected packages: pymupdf
  Running setup.py bdist_wheel for pymupdf ... error
  Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-JN8Hwk/pymupdf/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmpaDrZ6cpip-wheel- --python-tag cp27:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/fitz
  copying fitz/__init__.py -> build/lib.linux-x86_64-2.7/fitz
  copying fitz/fitz.py -> build/lib.linux-x86_64-2.7/fitz
  copying fitz/utils.py -> build/lib.linux-x86_64-2.7/fitz
  running build_ext
  building 'fitz._fitz' extension
  creating build/temp.linux-x86_64-2.7
  creating build/temp.linux-x86_64-2.7/fitz
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-PPrPZj/python2.7-2.7.15=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/mupdf -I/usr/local/include/mupdf -I/usr/include/python2.7 -c fitz/fitz_wrap.c -o build/temp.linux-x86_64-2.7/fitz/fitz_wrap.o
  fitz/fitz_wrap.c:2732:10: fatal error: fitz.h: No such file or directory
   #include <fitz.h>
            ^~~~~~~~
  compilation terminated.
  error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
  
  ----------------------------------------
  Failed building wheel for pymupdf
  Running setup.py clean for pymupdf
Failed to build pymupdf
Installing collected packages: pymupdf
  Running setup.py install for pymupdf ... error
    Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-JN8Hwk/pymupdf/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-nqzDYP-record/install-record.txt --single-version-externally-managed --compile --user --prefix=:
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/fitz
    copying fitz/__init__.py -> build/lib.linux-x86_64-2.7/fitz
    copying fitz/fitz.py -> build/lib.linux-x86_64-2.7/fitz
    copying fitz/utils.py -> build/lib.linux-x86_64-2.7/fitz
    running build_ext
    building 'fitz._fitz' extension
    creating build/temp.linux-x86_64-2.7
    creating build/temp.linux-x86_64-2.7/fitz
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-PPrPZj/python2.7-2.7.15=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/mupdf -I/usr/local/include/mupdf -I/usr/include/python2.7 -c fitz/fitz_wrap.c -o build/temp.linux-x86_64-2.7/fitz/fitz_wrap.o
    fitz/fitz_wrap.c:2732:10: fatal error: fitz.h: No such file or directory
     #include <fitz.h>
              ^~~~~~~~
    compilation terminated.
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
    
    ----------------------------------------
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-JN8Hwk/pymupdf/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-nqzDYP-record/install-record.txt --single-version-externally-managed --compile --user --prefix=" failed with error code 1 in /tmp/pip-build-JN8Hwk/pymupdf/

[JorjMcKie]

No - just verfied on Ubuntu Python2 and 3. You should see something like this

sudo -H python3.6 -m pip install -U pymupdf
Collecting pymupdf
  Downloading https://files.pythonhosted.org/packages/91/6b/8ffe64f7c16fdfc1559141d909444b337fa0e5461ce647660dcbb807700d/PyMuPDF-1.16.7-cp36-cp36m-manylinux2010_x86_64.whl (5.3MB)
     |████████████████████████████████| 5.3MB 1.4MB/s
Installing collected packages: pymupdf
Successfully installed pymupdf-1.16.7

And on Python2:

sudo -H python2 -m pip install -U pymupdf
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. More details about Python 2 support in pip, can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support
Collecting pymupdf
  Using cached https://files.pythonhosted.org/packages/d7/18/9a39fdcf9d0ce3811fe0d0a17f71cee7c2f007bdc3365ed4749ea9966301/PyMuPDF-1.16.7-cp27-cp27mu-manylinux2010_x86_64.whl
Installing collected packages: pymupdf
Successfully installed pymupdf-1.16.7
WARNING: You are using pip version 19.2.3, however version 19.3.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

[JorjMcKie]

I actually do not understand why pip tries to compile from source ...
This should only happen if it determines that none of the wheels are applicable to your Linux. A weird conclusion given that the new platform tag manylinux2010_x86_64 covers an even broader range of Linux variants than the old one.
Why don't you try manually downloading the wheel and force pip accepting it via specifying the wheel filename: pip install -U PyMuPDF-<...>.whl.

[cbm755]

I get the same error with Python 2.7. I can reproduce this across several machines (a VM and a CI docker setup). However, it works fine on my Fedora laptop.

Here's with the wheel directly (hopefully I got the correct file).

$ pip3 install --user PyMuPDF-1.16.7-cp36-cp36m-manylinux2010_x86_64.whl 
PyMuPDF-1.16.7-cp36-cp36m-manylinux2010_x86_64.whl is not a supported wheel on this platform.

$ uname -a
Linux 18k1-cbm1 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ pip3 --version
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)

[cbm755]

Here's a slightly more verbose version:

$ pip3 install --user -v PyMuPDF-1.16.7-cp36-cp36m-manylinux2010_x86_64.whl 
PyMuPDF-1.16.7-cp36-cp36m-manylinux2010_x86_64.whl is not a supported wheel on this platform.
Exception information:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/commands/install.py", line 330, in run
    wheel_cache
  File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 276, in populate_requirement_set
    wheel_cache=wheel_cache
  File "/usr/lib/python3/dist-packages/pip/req/req_set.py", line 245, in add_requirement
    wheel.filename
pip.exceptions.InstallationError: PyMuPDF-1.16.7-cp36-cp36m-manylinux2010_x86_64.whl is not a supported wheel on this platform.

[JorjMcKie]

This is weird. So your configuration is either really not supported by manylinux2010 - in which case you would indeed have to go the source installation path, including generation of MuPDF, or this is a false alarm.
I observed that your pip3 stems from medieval ages, and this might be a problem too. This is mine:

python3.6 -m pip --version
pip 19.3.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)

Why don't you upgrade pip in the first place.
Then you could also try renaming the wheel file. I know that pip's comaptibility checks are based on that name and not on any deepgrounded analysis of the binary. E.g. you could try names like

• PyMuPDF-1.16.7-cp36-cp36-manylinux2010_x86_64.whl
• PyMuPDF-1.16.7-cp36-none-manylinux2010_x86_64.whl
• PyMuPDF-1.16.7-cp36-cp36m-manylinux1_x86_64.whl
• etc.

As a last resort convert the wheel back to egg format using https://github.com/dairiki/humpty or similar. You can also unzip the wheel and manually copy the resulting files.

BTW - have you ever successfully installed PyMuPDF on this machine?

Whatever the outcome, you definitely should file a bug to the creator of the manylinux format repo https://github.com/pypa/manylinux.

[cbm755]

Yes previously to Nov 10, I never had any problems. My CI started breaking as soon as 1.16.7 came out. I will try some of those things "later".

My feeling is 18.04 is pretty common CI platform so I think a lot of people will hit this (assuming its not some weird problem local to me!)

[cbm755]

Upgrading pip seems to fix it...

So does PyMuPDF-1.16.7-cp36-cp36m-manylinux1_x86_64.whl! So that seems worth going upstream with... I will file.

[cbm755]

This comment of pypa/manylinux#338 sort of suggests its not supposed to work with old pip. That seems shortsighted given Ubuntu 18.04 is going to be a standard building block for some time yet... Anyway, will file an issue just in case

[cbm755]

Upstream issue: pypa/manylinux#389

[JorjMcKie]

Ahhh, glad to hear that ... sort of.
I will update the title of your issue to make it easier for others facing a similar problem.

[JorjMcKie]

Ok, fine.
Close issue?

[cbm755]

I think its manylinux2014 that requires 19. manylinux2010 seems to be pip 10 (pypa/manylinux#179).

For reference: pip 10 came out 2018-04-14 so it guess its no surprising Ubuntu 18.04 is still on pip 9.

[cbm755]

close: I guess so, you're not going back to manylinux1 I suppose!

[JorjMcKie]

close: I guess so, you're not going back to manylinux1 I suppose!

No, there is no way for me to do that - even if I would like to: non-Windows wheels are created by the cibuildwheel machinery on Travis CI, not by myself, everything fully automated.

[LiuHao-THU]

i solved this problem by upgrade python pip:

1. pip install --upgrade pip
2. pip install -U PyMuPDF

[AlisterH]

i solved this problem by upgrade python pip:

1. pip install --upgrade pip
2. pip install -U PyMuPDF

Not sure if this is expected, but it seems I have to do this every time, which surprised me.

[AlisterH]

My mistake - I got confused and was actually in a different environment from the one where I'd previously upgraded. But in any case I see a comment in another ticket from JorgMcKie saying that yes, pip should always be upgraded first.

[JorjMcKie]

i solved this problem by upgrade python pip:

1. pip install --upgrade pip
2. pip install -U PyMuPDF

Not sure if this is expected, but it seems I have to do this every time, which surprised me.

This is a recommendation and not always required. This procedure is also outlined / recommended in the documentation's installation section!
PyMuPDF is not alone recommending this: many packages with binary components do this the same.
I also would argue that this is no real problem: if your PIP is up to date, this will end up as a no-op.

However, a lot is going on in terms of Python platform support and consequential changes to PIP. The mean time between PIP versions in 2021 is clearly less than a month already (by end of October 13 versions in 2021 already).
In addition, the provider for wheel generations, Travis CI, has closed its free-of-charge services. So PyMuPDF had to switch, and chose Github Actions. This (presumably) entailed changes to the platform tag generated by cibuildwheel.