Uh oh!
There was an error while loading. Please reload this page.
ARROW-17016: [C++][Python] Move Arrow Python C++ tests into Cython - #14117
Conversation
8ff5341 to
afe5866CompareUh oh!
There was an error while loading. Please reload this page.
pitrou
left a comment
There was a problem hiding this comment.
Just some general comments. I will probably want to make some slight changes on the C++ side as well.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
AlenkaF
commented
Sep 27, 2022
Should we wait for ARROW-17843 so that the PyArrow C++ code is checked or we can correct that within the linter issue itself? |
pitrou
commented
Sep 27, 2022
We can correct the C++ linting later IMHO. |
AlenkaF
commented
Sep 27, 2022
The failures on the CI are not new, have seen them on the nightly builds. I think this PR is ready, totally approved from my side :) |
jorisvandenbossche
commented
Sep 27, 2022
@AlenkaF can you merge in or rebase on latest master? That should resolve those CI failures |
b8bffc2 to
ebeee04Comparepitrou
commented
Sep 28, 2022
@github-actions crossbow submit -g python -g wheel |
Revision: 7e4e2e653d8ce24cb3d8961fb386881114fda126 Submitted crossbow builds: ursacomputing/crossbow @ actions-6dfbce193c |
AlenkaF
commented
Sep 29, 2022
I think the failures of the wheels are related to the fact that |
pitrou
commented
Sep 29, 2022
Yes, we will probably need to enable all desired components manually. |
jorisvandenbossche
commented
Sep 29, 2022
Yes, that is getting fixed in #14273 |
AlenkaF
commented
Sep 29, 2022
You think I should wait for #14273 to get merged and then rebase? |
…d InferPrecisionAndNegativeScale
…return a Status and run them from Pytest
7e4e2e6 to
be21035Compare@pitrou@jorisvandenbossche this PR is now ready for final round of review/merge. |
jorisvandenbossche
commented
Oct 3, 2022
@github-actions crossbow submit -g python -g wheel |
Revision: be21035 Submitted crossbow builds: ursacomputing/crossbow @ actions-f48ddf2e66 |
pitrou
commented
Oct 3, 2022
Nothing seems to have changed since my last review, so I'm simply gonna merge! |
AlenkaF
commented
Oct 3, 2022
Thank you for running the wheels build - totally forgot that was what I was waiting to check :) |
ursabot
commented
Oct 4, 2022
Benchmark runs are scheduled for baseline = 441af34 and contender = 5fd54bc. 5fd54bc is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
ursabot
commented
Oct 4, 2022
['Python', 'R'] benchmarks have high level of regressions. |
…pers/python page (#14350) This PR updates Windows section of the Python Development page. Main changes: - use Python 3.10 (also in instructions for Linux/MacOs) - definition of `PATH` not needed as Python doesn't search in `PATH` for dlls anymore ([3.8 +](https://bugs.python.org/issue43173)) - use `CONDA_PREFIX` to define `ARROW_HOME` as in other parts of the docs - remove **Running C++ unit tests for Python integration** section (C++ unit tests are part of `pytest`-based test module as of #14117) cc @wjones127@jorisvandenbossche Authored-by: Alenka Frim <frim.alenka@gmail.com> Signed-off-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>
…pers/python page (#14350) This PR updates Windows section of the Python Development page. Main changes: - use Python 3.10 (also in instructions for Linux/MacOs) - definition of `PATH` not needed as Python doesn't search in `PATH` for dlls anymore ([3.8 +](https://bugs.python.org/issue43173)) - use `CONDA_PREFIX` to define `ARROW_HOME` as in other parts of the docs - remove **Running C++ unit tests for Python integration** section (C++ unit tests are part of `pytest`-based test module as of #14117) cc @wjones127@jorisvandenbossche Authored-by: Alenka Frim <frim.alenka@gmail.com> Signed-off-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>
…ke build system for the MATLAB interface (#37784) ### Rationale for this change This pull request removes `GoogleTest` support from the CMake build system for the MATLAB interface. 1. `GoogleTest` support adds a lot of additional complexity to the CMake build system for the MATLAB interface, and we currently don't have any standalone C++ tests for the MATLAB interface code. 2. In order to use `GoogleTest` in the MATLAB CI workflows, we are currently relying on building the tests for the Arrow C++ libraries in order to "re-use" the `GoogleTest binaries. This adds additional overhead to the MATLAB CI workflows. 3. If we want to test some internal C++ code for the MATLAB interface in the future, we can instead use a MEX function to call the code from a MATLAB test as suggested by @ kou in #37532 (comment). 4. There is [precedent for testing internal C++ code without GoogleTest for the Python bindings](#14117). 5. On a somewhat related note - removing `GoogleTest` support will help unblock #37773 as discussed in #37773 (comment). ### What changes are included in this PR? 1. Removed the `MATLAB_BUILD_TESTS` flag from the CMake build system for the MATLAB interface since there are no longer any C++ tests for the MATLAB interface to build. 2. Updated the `matlab_build.sh` CI workflow script to avoid building the tests for the Arrow C++ libraries and to no longer call `ctest`. 3. Updated the `README.md` for the MATLAB interface to no longer mention building or running C++ tests. 4. Updated the design document for the MATLAB Interface to no longer mention `GoogleTest` since we may end up testing internal C++ code using MEX function calls from MATLAB instead. 5. Removed placeholder C++ test (i.e. `placeholder_test.cc`). ### Are these changes tested? Yes. The MATLAB CI workflow is passing on all platforms. ### Are there any user-facing changes? Yes. There are no longer any C++ tests for the MATLAB interface. The `MATLAB_BUILD_TESTS` flag has been removed from the CMake build system to reflect this change. If a user supplies a value for `MATLAB_BUILD_TESTS` when building the MATLAB interface, the flag will be ignored by CMake. ### Future Directions 1. Add more developer-focused documentation on how to test C++ code via MEX function calls from MATLAB. ### Notes 1. In the future, we can consider testing internal C++ code using MEX function calls from MATLAB tests as suggested by @ kou in #37532 (comment). Currently, we don't have any C++ tests that need to be adapted to use this approach. 2. Thank you @ sgilmore10 for your help with this pull request! * Closes: #37532 Lead-authored-by: Kevin Gurney <kgurney@mathworks.com> Co-authored-by: Sarah Gilmore <sgilmore@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
…he CMake build system for the MATLAB interface (apache#37784) ### Rationale for this change This pull request removes `GoogleTest` support from the CMake build system for the MATLAB interface. 1. `GoogleTest` support adds a lot of additional complexity to the CMake build system for the MATLAB interface, and we currently don't have any standalone C++ tests for the MATLAB interface code. 2. In order to use `GoogleTest` in the MATLAB CI workflows, we are currently relying on building the tests for the Arrow C++ libraries in order to "re-use" the `GoogleTest binaries. This adds additional overhead to the MATLAB CI workflows. 3. If we want to test some internal C++ code for the MATLAB interface in the future, we can instead use a MEX function to call the code from a MATLAB test as suggested by @ kou in apache#37532 (comment). 4. There is [precedent for testing internal C++ code without GoogleTest for the Python bindings](apache#14117). 5. On a somewhat related note - removing `GoogleTest` support will help unblock apache#37773 as discussed in apache#37773 (comment). ### What changes are included in this PR? 1. Removed the `MATLAB_BUILD_TESTS` flag from the CMake build system for the MATLAB interface since there are no longer any C++ tests for the MATLAB interface to build. 2. Updated the `matlab_build.sh` CI workflow script to avoid building the tests for the Arrow C++ libraries and to no longer call `ctest`. 3. Updated the `README.md` for the MATLAB interface to no longer mention building or running C++ tests. 4. Updated the design document for the MATLAB Interface to no longer mention `GoogleTest` since we may end up testing internal C++ code using MEX function calls from MATLAB instead. 5. Removed placeholder C++ test (i.e. `placeholder_test.cc`). ### Are these changes tested? Yes. The MATLAB CI workflow is passing on all platforms. ### Are there any user-facing changes? Yes. There are no longer any C++ tests for the MATLAB interface. The `MATLAB_BUILD_TESTS` flag has been removed from the CMake build system to reflect this change. If a user supplies a value for `MATLAB_BUILD_TESTS` when building the MATLAB interface, the flag will be ignored by CMake. ### Future Directions 1. Add more developer-focused documentation on how to test C++ code via MEX function calls from MATLAB. ### Notes 1. In the future, we can consider testing internal C++ code using MEX function calls from MATLAB tests as suggested by @ kou in apache#37532 (comment). Currently, we don't have any C++ tests that need to be adapted to use this approach. 2. Thank you @ sgilmore10 for your help with this pull request! * Closes: apache#37532 Lead-authored-by: Kevin Gurney <kgurney@mathworks.com> Co-authored-by: Sarah Gilmore <sgilmore@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
…he CMake build system for the MATLAB interface (apache#37784) ### Rationale for this change This pull request removes `GoogleTest` support from the CMake build system for the MATLAB interface. 1. `GoogleTest` support adds a lot of additional complexity to the CMake build system for the MATLAB interface, and we currently don't have any standalone C++ tests for the MATLAB interface code. 2. In order to use `GoogleTest` in the MATLAB CI workflows, we are currently relying on building the tests for the Arrow C++ libraries in order to "re-use" the `GoogleTest binaries. This adds additional overhead to the MATLAB CI workflows. 3. If we want to test some internal C++ code for the MATLAB interface in the future, we can instead use a MEX function to call the code from a MATLAB test as suggested by @ kou in apache#37532 (comment). 4. There is [precedent for testing internal C++ code without GoogleTest for the Python bindings](apache#14117). 5. On a somewhat related note - removing `GoogleTest` support will help unblock apache#37773 as discussed in apache#37773 (comment). ### What changes are included in this PR? 1. Removed the `MATLAB_BUILD_TESTS` flag from the CMake build system for the MATLAB interface since there are no longer any C++ tests for the MATLAB interface to build. 2. Updated the `matlab_build.sh` CI workflow script to avoid building the tests for the Arrow C++ libraries and to no longer call `ctest`. 3. Updated the `README.md` for the MATLAB interface to no longer mention building or running C++ tests. 4. Updated the design document for the MATLAB Interface to no longer mention `GoogleTest` since we may end up testing internal C++ code using MEX function calls from MATLAB instead. 5. Removed placeholder C++ test (i.e. `placeholder_test.cc`). ### Are these changes tested? Yes. The MATLAB CI workflow is passing on all platforms. ### Are there any user-facing changes? Yes. There are no longer any C++ tests for the MATLAB interface. The `MATLAB_BUILD_TESTS` flag has been removed from the CMake build system to reflect this change. If a user supplies a value for `MATLAB_BUILD_TESTS` when building the MATLAB interface, the flag will be ignored by CMake. ### Future Directions 1. Add more developer-focused documentation on how to test C++ code via MEX function calls from MATLAB. ### Notes 1. In the future, we can consider testing internal C++ code using MEX function calls from MATLAB tests as suggested by @ kou in apache#37532 (comment). Currently, we don't have any C++ tests that need to be adapted to use this approach. 2. Thank you @ sgilmore10 for your help with this pull request! * Closes: apache#37532 Lead-authored-by: Kevin Gurney <kgurney@mathworks.com> Co-authored-by: Sarah Gilmore <sgilmore@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
This PR tries to connect the PyArrow C++ tests with PyArrow tests so they can all be run from
pytest. This will remove GoogleTest as a dependency for PyArrow and therefore a change is needed in the C++ tests so they return a Status which can then be checked through Cython/Python.Example of pytest run: