Conversation
|
I initially thought that there's now a hard requirement for NumPy v2 with SciPy v1.14.0, but that doesn't seem to be the case. I might need to provide hints to Meson/ Note to self: I need to go through the changes in scipy/scipy@3c37112 and scipy/scipy@d85ba6b. |
|
You can build SciPy 1.14 against NumPy 1.26 just fine - only need to remember to then rebuild SciPy when NumPy 2.0 lands. |
|
If |
|
Yes. I realise that the error is because while NumPy is indeed built beforehand, it isn't installed into the environment, and therefore the |
|
Okay, managed to fix this – I have had to revert all the uses of the f2py generator calls I could find, which were from your commit I mentioned above, @rgommers; it isn't an ideal solution since it conflicts with other patches and the diff is quite big (in terms of both tidiness and upstream-ability – or rather, the lack of them). Although, my hunch is that we don't need to do this at all, though, and simply restoring the Edit: it does, in fact – Meson generators are pretty neat! :) We are now able to start compiling SciPy v1.14.0. However, it fails with the following logs (truncated here): Tap to view logsIt suggests we are compiling a shared library somewhere, but I don't see anything in the log file; it's the same as the above trace. I'm now going to try to find out where a shared library has been defined in the target definitions (and where that changed between v1.13.0 and v1.14.0). I'm also going to try passing additional arguments to the |
|
@agriyakhetarpal perhaps scipy/scipy#20321? |
|
Thank you, @lucascolley – will take a look! |
|
Never mind, patch 15 doesn't seem to work, based on the error raised in CI – I think we'll have to remove the f2py generators entirely unless I'm missing any other ways to fix this. I think I had an Also, I now have an issue locally: the build procedure is trying to compile Tap to view logs |
I'm not sure, probably best to defer to @steppi on that one |
|
I'm not facing the error in CI, i.e., |
|
The test failure for Firefox is unrelated – I increased the PyArrow timeout to six times the original value in 828a08f. I'm assuming that a value of |
|
Cool, thanks @agriyakhetarpal!
I think you've already figured it out, but FWIW, I use |
I think we need to fix this somehow... we ignore numpy even if it is specified as a build requirement in the pyproject.toml (code pointer, but it has been a problem for a few use cases (#4160). |
|
Thanks for the super quick review, @ryanking13! I did run I have faced #4160 before with some other packages that I was updating that had a dependency on NumPy, so thanks for the pointer. Either way, I'm not super satisfied with the patch, and I wouldn't suggest reverting something in SciPy that made their lives happy just so that it makes ours happy too – so, one way to work around the mess could be to write a Python script for this purpose that would go through the |
Let me see if I can fix it in pyodide-build side. |
Sure, thanks! I saw this comment a little late and was working on my script-based idea in the meantime, but ultimately anything is better than a script that we need to keep maintaining. |
It's L-BFGS-B and ARPACK on its way. Should it be SLSQP next? Otherwise will be PROPACK. |
Sorry, I missed the ping while traveling. If it's too much trouble to get the shared library working, I'd prefer removing the special error handling functionality altogether rather than shipping a broken version that only works for half of the functions. |
Hi @ilayn – pinging @lesteve who would have more experience and can answer this better than I would, since he has historically maintained the SciPy test suite for Pyodide in a separate repository at https://github.com/lesteve/scipy-tests-pyodide (though it now runs with the
No worries, @steppi. I converted the shared library to a static one to allow compilation to proceed, and fortunately, all the tests passed, we're not seeing anything problematic. |
No strong opinion on this, I would think that making Pyodide's life easier for Scipy support is only a small part of the story behind the Fortran rewrite. |
Definitely and at the same time, we can make life easier by attacking the more problematic ones earlier for Pyodide. For me, the order does not matter, they are all excessively boring work, but it might matter for you. But I guess we tackled the bigger problems so we are at the noise level in terms of preference which is good news for me. I'll see which one is a quicker win then. |
|
Thanks for the reviews! I initially thought I could wait until we can get the install tags functionality working, but I think that is not a blocker because we remove the tests away anyway using |
|
This seems fine to me to merge. I'll comment on the f2py generator issue higher up - that patch isn't desirable, but let's not let that block a merge, hopefully we can figure that one out and remove the patch again later. |
|
Thanks, Ralf! Merged this, then. I'll put up a PR for the next version. |
…sting (#7525) This PR follows up on changes made in gh-7350. Here's a small, point-wise summary noting the changes here: - It updates the Emscripten/Pyodide CI job added in gh-7350 and removes the workaround JavaScript-based test suite file, since we fixed the `s_cmp` OpenBLAS unresolved symbol coming from SciPy upstream, having updated SciPy in-tree in Pyodide (see pyodide/pyodide#4719, pyodide/pyodide#5012, pyodide/pyodide#5031, and more). This should make the testing slightly cleaner than before, and the test suite now runs till the end without any Pyodide fatal errors being reported. The [Pyodide xbuildenv](https://github.com/pyodide/pyodide/releases/tag/0.27.0a2) can now be used to set up a virtual environment in which the tests can be run in the same way they were before. The [`pyodide-build` tool](https://github.com/pyodide/pyodide-build) has been unvendored from the Pyodide repository and now infers the Pyodide version from the releases, downloading the relevant files from the GitHub release. Hence, the `PYODIDE_VERSION` environment variable is no longer required. - There were some tests that have been failing on 32-bit platforms, which were last discussed quite a while ago: #3091. They surprisingly passed in a WASM 32-bit environment here without issues, which is great. I have updated the skipping conditions to accommodate this. - There's a known problem with the pytest bytecode generation when running the tests with the xbuildenv interpreter – I disabled the pytest internal cache plugin to fix that, but ignoring the warning (pypa/cibuildwheel#1966 (comment)) works equally as well. Please let me know if there is a preference. :) Additional context - Pyodide CI support was first discussed in gh-7265. - At the time of writing, Pyodide 0.27alpha2 is used in the CI job; once 0.27 stable comes out (should be soon) and `cibuildwheel` updates to it, that (plus this PR) will help unblock another PR that I had opened a while back: gh-7440. I can rebase that PR when ready. - pyodide/pyodide#4871 (comment) --- Co-authored-by: Lars Grüter <[email protected]>
8 participants
Description
This PR updates SciPy to version 1.14.0. Tagging recipe maintainers: @lesteve, @steppi; and @rgommers, for visibility. SciPy was previously updated in #5011 to version 1.13.1.
Checklists