Package Base Details: python2-pymupdf

Git Clone URL: (read-only)
Submitter: nabla
Maintainer: cges30901
Last Packager: cges30901
Votes: 6
Popularity: 1.56
First Submitted: 2015-12-07 14:49
Last Updated: 2019-11-09 14:12

Latest Comments

1 2 Next › Last »

alium commented on 2019-10-29 19:24

thank you!

cges30901 commented on 2019-10-29 15:10

@akobel @alium Now I am the new maintainer of this package, and I have changed it to build from source.

cges30901 commented on 2019-10-06 09:20

@alium: There was a package called python-mupdf that built PyMuPDF from source tarball, but now it is deleted.

@akobel: Your PKGBUILD doesn't work for me.

EDIT: For the build error for python2, see Issue #320. SWIG is needed if you download source from Github, but it's not needed if you download source from PyPI, so this error is not present.

akobel commented on 2019-09-22 17:29

@alium: The reason was that upstream used to only provide releases as wheels, not as source tarballs.

That's not a reason anymore. The default procedure works, but as far as I can see, only for Python3 (with python2, there's a TypeError: super() taking at least 1 argument). In short, this package (as python2-pymupdf is the base) seems outdated beyond quick fixes, unless anyone wants to whack it until it works, i.e., backport via the PKGBUILD.




pkgdesc='Python bindings for MuPDF'








package() {

cd "${srcdir}/${_pkgname}-${pkgver}"

python build

python install --root="$pkgdir" --optimize 1


(minus those angle brackets in the URL) works.

@nabla: Do you still want to maintain this package? What's your stance on @alium's proposal, and do you think Python2 compatibility can be achieved easily?

alium commented on 2019-09-10 08:30

stupid question: why you can not use normally

python build

python install --root="$pkgdir" --optimize=1

as others python packages is [extra/community]??

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.