8000 py-scipy: add v1.14.0 by adamjstewart · Pull Request #44967 · spack/spack · GitHub
[go: up one dir, main page]

Skip to content

py-scipy: add v1.14.0 #44967

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 1, 2024
Merged

py-scipy: add v1.14.0 #44967

merged 2 commits into from
Jul 1, 2024

Conversation

adamjstewart
Copy link
Member

https://github.com/scipy/scipy/releases/tag/v1.14.0

@rgommers I would be interested in getting Accelerate working in the future. Spack only supports a single BLAS/LAPACK library in the DAG at a time. If I understand correctly, SciPy supports Accelerate now, but NumPy still doesn't? Are there plans for NumPy to support Accelerate? I don't even know where to start with adding an Accelerate package to Spack, not sure if you know where libraries live, how to check what versions are present, how those versions map to BLAS/LAPACK API versions, etc.

@adamjstewart
Copy link
Member Author

../meson.build:138:12: ERROR: Program 'pythran' not found or not executable

I know we had this problem before, but I don't remember how we solved it.

@rgommers
Copy link
Contributor

Are there plans for NumPy to support Accelerate?

NumPy supports it already; the macosx_14_0 wheels in the 2.0.0 release are built against Accelerate. It was

I don't even know where to start with adding an Accelerate package to Spack, not sure if you know where libraries live, how to check what versions are present, how those versions map to BLAS/LAPACK API versions, etc.

The libraries and headers are in a system location; they'll be on the search path even when you're using compilers other than Apple Clang.

Versions are directly tied to macOS version: on macOS >=13.3 the new Accelerate is always available, and it provides a LAPACK 3.9 API. In macOS 15.0 that will be upgraded to LAPACK 3.11. numpy/numpy#24053 may be instructive to look at.

The main problem for Spack may be symbol naming; the symbol suffixes to access the updated library at $NEWLAPACK or $NEWLAPACK$ILP64. Not all packages that need LAPACK will have support for custom symbol suffixes (it was a massive job to implement that for SciPy).

@rgommers
Copy link
Contributor

../meson.build:138:12: ERROR: Program 'pythran' not found or not executable

I know we had this problem before, but I don't remember how we solved it.

See #42213 (comment). The problem was a too old version of setuptools. Looking at this log, it pulls in setuptools 46.1.3, which is ridiculously old.

@rgommers rgommers mentioned this pull request Jun 30, 2024
@adamjstewart
Copy link
Member Author

Okay, hoping the last commit fixes this. Spack is using a newer version of setuptools to build pythran (as instructed). However, we have no constraints on the version of setuptools present at run-time. I don't know why an older version was chosen, but the latest commit should force a newer version to be used at run-time as well. I didn't realize the version of setuptools present at run-time mattered for pythran but it seems that that's the case.

@adamjstewart adamjstewart requested a review from alalazo July 1, 2024 08:19
Copy link
Member
@alalazo alalazo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, @rgommers do you have any comments?

Copy link
Contributor
@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, seems ready to merge.

I didn't realize the version of setuptools present at run-time mattered for pythran but it seems that that's the case.

It seems odd indeed. It may not be inside pythran itself, but rather than setuptools is somehow used in however Spack has implemented entrypoint support for Python.

@alalazo alalazo merged commit 78c6253 into spack:develop Jul 1, 2024
13 checks passed
@adamjstewart adamjstewart deleted the packages/py-scipy branch July 1, 2024 13:29
hariharan-devarajan pushed a commit to hariharan-devarajan/spack that referenced this pull request Jul 10, 2024
FrederickDeny pushed a commit to FrederickDeny/spack that referenced this pull request Aug 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0