Package Details: python-scikit-image 0.16.2-1

Git Clone URL: (read-only, click to copy)
Package Base: python-scikit-image
Description: Image processing routines for SciPy
Upstream URL:
Licenses: BSD
Submitter: Dragonlord
Maintainer: Universebenzene
Last Packager: Universebenzene
Votes: 54
Popularity: 0.90
First Submitted: 2016-04-30 10:32
Last Updated: 2019-10-22 08:49

Dependencies (15)

Sources (1)

Latest Comments

1 2 3 4 Next › Last »

jdc commented on 2020-04-14 16:55

I'm getting an error when I try to import

dburkhardt commented on 2019-05-17 13:52

I'm getting a conflicting package error when I shouldn't be:

looking for conflicting packages...
:: python-scipy and python-scipy-openblas are in conflict. Remove python-scipy-openblas?

But python-scipy-openblas is listed as sufficient in the Dependencies table. What's going on?

Universebenzene commented on 2019-03-07 14:08

@bertptrs Fine, so I bring back the build() function now. Thanks!

bertptrs commented on 2019-03-07 13:58

You are right on the prepare() part; I've misread the diff. And while the package builds fine, the problem of compiling in package_*() is more of a semantic one. Some packages (quite a few unfortunately) compile source code in the prepare() phase, but this is incorrect. Most python packages only need to byte-compile all of their .py files. For this package it is especially noticeable as there is a lot of actual native code compilation.

The correct way to do it is: have a build() that calls python(2) build for both versions, and then in each package_ function call python(2) install …. The package function really should only be moving files from here to there. Just because you can compile the packages there doesn't mean you should. One might want to inspect the created binaries before creating a package, for example, or really just any use of makepkg --repackage.

You can see an example in the PKGBUILD for numpy: (and also the previous versions of this package)

Universebenzene commented on 2019-03-07 13:12

Hi @bertptrs, actually I don't have build() function in the PKGBUILD, and I am modifying the source code in prepare() function , not build(). In fact for most python packages, the python install does the build at the same time, so we don't really need another build() for them. The package builds well on my PCs, so could you please tell me what kinds of errors occur on yours? Thanks for feedback.

bertptrs commented on 2019-03-07 12:45

Hi, I see you modified the PKGBUILD quite a bit, and with it introduced some errors. Would you mind going back to the old style?

Currently, it modifies source code in build() rather than prepare() and also compiles code in package() rather than in build(). Both are bad practices, and the PKGBUILD did this correctly before the latest commit. Please see

Dragonlord commented on 2019-03-05 20:24

Package disowned.

Universebenzene commented on 2019-02-27 12:42

The PKGBUILD produced by @greyltc works well. Are you still maintaining this package? If you got any problem, we can discuss here, or please update this package ASAP. This package is related to several other packages, so if you don't update it to 0.14.2, they may all get problems.

versusvoid commented on 2019-01-29 10:02

Please, split PKGBUILD into two distinct packages, so I would not have to install all the python2 dependencies just to build python2 version, when I have no need for it in the first place. It would build faster, download less, there will be peace on Earth and everyone will be happy. Yeah, it would mean duplicating some common fields across two PKGBUILDs, but IMO it worth the gain.

greyltc commented on 2019-01-28 12:11

Fixed PKGBUILD is here: