Package Details: python-numpy-openblas 1.22.0-2

Git Clone URL: https://aur.archlinux.org/python-numpy-openblas.git (read-only, click to copy)
Package Base: python-numpy-openblas
Description: Scientific tools for Python - built with openblas
Upstream URL: http://numpy.org/
Licenses: custom
Conflicts: python-numpy, python3-numpy
Provides: python-numpy=1.22.0, python3-numpy=1.22.0
Submitter: xia0er
Maintainer: xia0er
Last Packager: xia0er
Votes: 25
Popularity: 1.54
First Submitted: 2013-11-21 20:38
Last Updated: 2022-01-11 21:12

Required by (1000)

Sources (1)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

bnavigator commented on 2022-01-06 20:35

You should determine the sitelib path dynamically:

https://wiki.archlinux.org/title/Python_package_guidelines

xia0er commented on 2022-01-06 20:24

@gnaggnoyil, fixed. Thanks for pointing this out.

gnaggnoyil commented on 2022-01-06 15:36

Current version of core/python is 3.10 while PYTHONPATH is set to /usr/lib/python3.9 in check of PKGBUILD. I think either PYTHONPATH needs to be updated to match current core/python version or a python=3.9 dependency needs to be explicitly specified in the dependencies section.

Xyne commented on 2020-12-05 18:10

Can you please add python-hypothesis to the makedepends array. It's required for the check function. Thanks!

mdeff commented on 2020-10-08 11:12

Yes a distribution-wide switch would be ideal (Arch does it for Java, and others like Debian have a generic method that they use for BLAS too).

bnavigator commented on 2020-10-05 11:49

Hi,

the mentioned ArchWiki page and an Archlinux wide switching approach would be greatly appreciated.

See also https://github.com/python-control/Slycot/issues/138#issuecomment-703573577

hairyass commented on 2020-05-29 02:46

I like this package because it just works. It removes all the conflicting packages, so please keep this package

E3LDDfrK commented on 2020-04-07 17:54

I was thinking about creating an ArchWiki page that explains what is BLAS & LAPACK, which packages use them, what are the available providers, and how to switch. This could be linked from the user package wikis (numpy, R, julia, etc.). Would that solve the issue in your opinion?

@mdeff That sounds great.

mdeff commented on 2020-04-07 11:35

@xia0er, thanks for your consideration. Isn't it overkill to have to rebuild the package for an additional dependency? Also, such a policy quickly explodes, as you'd need every <package>-<blas> combinations with {numpy, scipy, julia, r, pytorch, tensorflow, opencv, arpack, etc.} as packages and {netlib, openblas, mkl, blis, atlas} as blas. I think it's cleaner for user packages to depend on {blas, cblas, lapack, lapacke} and for provider packages to provide those. Users then choose which provider to install.

I was thinking about creating an ArchWiki page that explains what is BLAS & LAPACK, which packages use them, what are the available providers, and how to switch. This could be linked from the user package wikis (numpy, R, julia, etc.). Would that solve the issue in your opinion?

In the longer term, Arch should ideally allow the installation of multiple providers and have a mechanism to easily switch the default, like Debian, Gentoo, conda-forge (Arch does it for java).

Do you remember where the discussion about not including LAPACK in community/openblas happened? I searched as much as I could and didn't find any. In my opinion it's a serious issue (most serious being the omission of the C bindings), and the maintainer doesn't seem responsive. :/

xia0er commented on 2020-04-06 18:09

@mdeff Just checked out the FS#s you linked to. If the community/openblas eventually includes lapack, I agree this package can be sunset/removed, but I'd like to keep it active before that.