Closed bkpoon closed 4 months ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@conda-forge-admin please rerender
I tested the patched Boost libraries with the code that I maintain with numpy versions 1.19 to 2.0, and the tests pass with the patched libraries. We have numerical arrays exposed to Python using Boost and we get segmentation faults without the fix (numpy 2 migrator for cctbx-base package)
I ran the tests with GitHub Actions and tested linux, Windows, and macOS (Intel and Apple Silicon). The patched packages for Boost and cctbx-base are on my testing channel (https://anaconda.org/cctbx-dev).
numpy | Python | Test results |
---|---|---|
1.19 | 3.9 | https://github.com/cctbx/cctbx/actions/runs/10015271694 |
1.20 | 3.9 | https://github.com/cctbx/cctbx/actions/runs/10015685246 |
1.21 | 3.9, 3.10 | https://github.com/cctbx/cctbx/actions/runs/10015783111 |
1.22 | 3.9, 3.10 | https://github.com/cctbx/cctbx/actions/runs/10016155821 |
1.23 | 3.9, 3.10, 3.11 | https://github.com/cctbx/cctbx/actions/runs/10016930571 |
1.24 | 3.9, 3.10, 3.11 | https://github.com/cctbx/cctbx/actions/runs/10017112169 |
1.25 | 3.9, 3.10, 3.11 | https://github.com/cctbx/cctbx/actions/runs/10020687839 |
1.26 | 3.9, 3.10, 3.11, 3.12 | https://github.com/cctbx/cctbx/actions/runs/10021771130 |
2.0 | 3.9, 3.10, 3.11, 3.12 | https://github.com/cctbx/cctbx/actions/runs/10023084470 |
There is a Test environment info
step that lists the packages in the testing environment and a Run subset of tests
step for the actual tests that are run.
My concern with run_constrained
is that there is probably code that is wrapped with Boost.Python, but does not go through this particular code path. If they have numpy
in their environment, it would be updated unnecessarily. Considering that there have not been any other issues raised about this seems to indicate that this code path is not too common.
I can add the run_constrained
option if always updating numpy
is okay. Thoughts? Thanks!
What are the next steps here?
What are the next steps here?
Rebase, or at least fix the conflict.
I can add the
run_constrained
option if always updatingnumpy
is okay. Thoughts?
Thanks for the extensive testing. IIUC, things work with numpy 1.19 (which is the absolute lowest bound that any package produced here would require anyway), so then we don't need to add anything else here.
@conda-forge-admin , please re-render
Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/boost-feedstock/actions/runs/10068564811.
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml
) and found it was in an excellent condition.
That should fix the conflict
Anything else?
Checking in to see if anything else needs to be done. Thanks!
Thank you!
Thanks! Feel free to ping me if there are any issues.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)This fixes an issue that came up starting with numpy 1.21 (segmentation faults in certain cases where a C++ array was exposed to Python), but was patched in numpy. numpy 2 removed the fix so the solution is to fix Boost. More details are described in this issue (https://github.com/boostorg/python/issues/376). The upstream PR in Boost is here (https://github.com/boostorg/python/pull/443).