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
MAINT: 1.9.2 backports #17132
MAINT: 1.9.2 backports #17132
Conversation
Co-authored-by: Julien Jerphanion <git@jjerphan.xyz> Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com> Co-authored-by: Thomas J. Fan <thomasjpfan@gmail.com>
We're interested in moving to the modern `cibuildwheel` machinery for the release/wheel build process, following NumPy/pandas, etc. [skip actions] [skip circleci] [skip ci] [skip azp]
This resulted in `{py_purelib}/` entries in `<build-dir>/meson-info/intro-install_plan.json`, and there should be zero of those. [skip azp] [skip circle]
Issue materialized with MSVC as: ``` cl : Command line error D8021 : invalid numeric argument '/Wno-cpp' ``` [skip actions] [skip circle]
[skip actions] [skip circle]
If the detection happens via CMake, that results in an upper-case result for `blas.name()`. So deal with any case, and also that of using `-Dblas=mkl_rt`. Note that this does not fix things for using CMake, because that defaults to the ILP64 interface (xref scipygh-16988). Add notes on what is left for MKL support Also add g77 ABI wrapper and fix a typo in f2py signature file in `_propack` Note that this is an incomplete fix, because PROPACK is in a bad state, as discussed in the issue linked in the code comment.
Update the cibuildwheel version used in the wheels.yml configuration from 2.9.0 to 2.10.1. This is mainly usefull for the updated CPython 3.11 version (from 3.11.0rc1 to v3.11.0rc2). [wheel build]
Resolve the large precision error of truncnorm.logcdf with upper tail argument. mass_case_central of _log_gauss_mass was inaccurate due to catastrophic cancellation in logsumexp.
FIX: ensure a hold on GIL before raising warnings/errors
Require "meson-python>=0.9.0", "Cython>=0.29.32", "pybind11>=2.10.0" and "pythran>=0.12.0" to build SciPy. These updated build-system requirements allow for consistent builds. The updated meson-python and Cython helps with Python 3.11 builds. Probably a backport candidate to the 1.9 branch if Python 3.11 wheels are to be released on this branch. (note that build-system requirements are only needed to build SciPy from source, not to run it after a regular pip install, and thus can be set fairly aggressive). [wheel build]
@tylerjereddy gh-16814 and gh-17055 just merged, can we add them here? Shall I open a PR against your branch, push here, or let you do it? |
* clean up some of my own mistakes from merge conflict resolution in the build system
Eh, there are still |
That requires backporting the relevant fix from gh-17057 (EDIT: done). The doc build is failing on a single Matplotlib deprecation warning for I will have a look at the build failures and push fixes for them. |
This will solve the failure of the "build from sdist" job in Azure.
(cherry picked from commit 076a1f0)
…tive byte order. (scipy#17035) (cherry picked from commit 29ec80b)
I think it's pretty close now. It is quite a bit of churn, but I don't see a good alternative for Python 3.11 unless we pull the 1.10.0 release way forward - which is likely a lot more work. |
See scipygh-16926 (cherry picked from commit 81f4a4c)
There's a PendingDeprecationWarning for this introduced in Matplotlib 3.6 (released 16 Sep 2022). It should be fine to depend on latest Matplotlib in this one example. [skip azp] [skip actions]
40fccfa
to
9e4289a
Compare
Brings these more in line with `main`
9e4289a
to
2bc973a
Compare
Okay, all the regular CI should work now, and I also pushed a change to CI triggering for If this is all green, I think the PR is ready to merge, and after that it needs one more commit to set the version number to |
Interesting, did you fix the MacOS Python 3.11 certificate issue somehow or did that just go away with a dependency update somewhere? |
See #17132 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even aarch64 on QEMU seems happy. The one thing that this PR does not yet do is uncomment the Upload wheels
section of wheels.yml
. I think that can be done separately - or in this PR without re-testing. Let's just confirm that the code is identical there between main
and 1.9.x
.
Can we get these two bug fixes in? #17132 (comment) |
@mdhaber I may do those separately but will try to get them in--the diff here is getting close to 4,000 lines. Let me try to skim this PR over one more time then I'll probably merge it based on Ralf's recommendation/fixes. |
Great, thanks! |
Try to get ready for SciPy
1.9.2
and release of Python3.11
(and other) wheels viacibuildwheel
infrastructure. Merge conflicts related to build system infrastructure were extreme--any PR with a backport label that modified code that doesn't even exist on the maintenance branch had its backport label stripped and a comment added to the PR explaining why.In cases where I saw that I could cleanly apply a patch to the build system, but the context in flanking code had changed radically, I applied the patch nonetheless--for example, many meson data structures were using things like
py3_dep
on maintenance branch but neither before nor after on the labeled backport PRs--in these cases I apply the patch directly and assume that the context change is safe (otherwise the burden of reinterpretation of the code would be huge).Also, remember that this branch still uses
do.py
notdev.py
, to give you an idea of how much stuff has drifted..Backports currently included (those excluded should have a recent comment from me, I'll go back and check notifications to see what else needs to be backported... there will be more..):
_stack_along_minor_axis
#16628linear_sum_assignment
to PyCFunction #16934axis!=1
,nan_policy='omit'
,keepdims=False
#16954get_install_data
, which defaults to purelib #16969truncnorm.logcdf
when cdf is nearly 1 #17064