Package Details: python2-pymupdf 1.14.8-1

Git Clone URL: (read-only)
Package Base: python2-pymupdf
Description: Python bindings for MuPDF
Upstream URL:
Licenses: AGPL3
Submitter: nabla
Maintainer: nabla
Last Packager: nabla
Votes: 4
Popularity: 0.595566
First Submitted: 2015-12-07 14:49
Last Updated: 2019-03-02 11:59

Latest Comments

akobel commented on 2019-01-22 12:19

@wenbushi: What matters IMHO is that two files are downloaded, but only one is necessary if the user only needs either Python 2 or 3. Nitpicking: The package name is not misleading, as there are two distinct package names for the two distinct packages that are built from the common package base. And it seems to be customary to use one of the package names as the name for the base, too, for those python packages (which might not necessarily be a good idea).

Anyway, let's leave that up to @nabla - unlike the missing --ignore-installed, it doesn't affect the usability of the package, so it's not a huge concern to me.

wenbushi commented on 2019-01-21 11:36

@akobel: Yeah, perhaps I didn't make myself clear. What only matters is that the package name may cause a little confusion.

akobel commented on 2019-01-20 14:07

@wenbushi: Ah, now I see your point; I though you refered to the build problem mentioned by marlemion.

True: For the user who only needs one package, separate PKGBUILDs have the benefit that you only download one wheel. That wasn't the case for "real" builds from source, where you base both packages on the same source. From a maintenance point of view, one common PKGBUILD is slightly more convenient, I guess.

So, no strong opinion from my side (but then, I currently have both versions installed).

wenbushi commented on 2019-01-20 09:48

@akobel: By convention python-pymupdf implies python3-pymupdf. Is it really necessary to put python2-pymupdf and python3-pymupdf together in one PKGBUILD?

akobel commented on 2019-01-14 14:40

@wenbushi: Note that the failure has nothing to do with the fact that both the Python 2 and 3 versions are built from the same PKGBUILD; it's because this build uses the wheel distributed upstream rather than building from source.

wenbushi commented on 2019-01-14 12:44

Maybe it's more convenient to separate python-pymupdf and python2-mupdf as two packages.

akobel commented on 2019-01-09 11:32

Indeed. Problem is that the previous version is visible during the makepkg stage, and pip tries to uninstall it, but isn't (and shouldn't be) allowed to; the former version gets removed when the new package gets installed, not when it's built.

Workaround: first uninstall python{,2}-pymupdf, then re-install the new version.

Fix: add --ignore-installed in the PKGBUILD's package commands for pip and pip2; that is, replace the two occurences of install --root="${pkgdir}" by install --root="${pkgdir}" --ignore-installed.

marlemion commented on 2019-01-09 07:49

Package build fails with makepkg:

makepkg ==> Making package: python2-pymupdf 1.14.5-1 (Wed Jan 9 08:49:17 2019) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found PyMuPDF-1.14.5-cp27-cp27mu-manylinux1_x86_64.whl -> Found PyMuPDF-1.14.5-cp37-cp37m-manylinux1_x86_64.whl ==> Validating source files with sha256sums... PyMuPDF-1.14.5-cp27-cp27mu-manylinux1_x86_64.whl ... Passed PyMuPDF-1.14.5-cp37-cp37m-manylinux1_x86_64.whl ... Passed ==> Extracting sources... ==> Removing existing $pkgdir/ directory... ==> Entering fakeroot environment... ==> Starting package_python2-pymupdf()... Processing ./PyMuPDF-1.14.5-cp27-cp27mu-manylinux1_x86_64.whl Installing collected packages: PyMuPDF Found existing installation: PyMuPDF 1.13.19 Uninstalling PyMuPDF-1.13.19: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/usr/lib/python2.7/site-packages/PyMuPDF-1.13.19.dist-info/INSTALLER' Consider using the --user option or check the permissions.

==> ERROR: A failure occurred in package_python2-pymupdf(). Aborting...