Add thirdparty tests of numba extensions

[brandon-b-miller]

This PR introduces an extra job that is intended to test thirdparty libraries whom depend on the numba extension api in a complex way.

[copy-pr-bot]

Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[gmarkall]

/ok to test

[gmarkall]

I'm not sure I've understood the idea behind this PR - wouldn't it be simpler and more comprehensive to have a CI job that installs cuDF with the numba-cuda wheel we built, and runs its UDF tests, rather than adding our own new tests that depend on cuDF?

[brandon-b-miller]

cuDF doesn't ship it's tests - we could probably vendor them wholesale but it seems a bit over kill. These felt like a small enough group of smoke tests to touch all it's usage of numba's extension API

[gmarkall]

cuDF doesn't ship it's tests - we could probably vendor them wholesale but it seems a bit over kill. These felt like a small enough group of smoke tests to touch all it's usage of numba's extension API

Can we do a shallow clone of the cuDF repo instead?

[brandon-b-miller]

cuDF doesn't ship it's tests - we could probably vendor them wholesale but it seems a bit over kill. These felt like a small enough group of smoke tests to touch all it's usage of numba's extension API

Can we do a shallow clone of the cuDF repo instead?

It's an option, but I believe there are some tradeoffs here. If we always clone main, there's a good chance our CI is broken whenever cuDF's CI is broken. We could avoid this by checking out a static commit or release, but I think that might be something we'd need to keep up to date manually.

The other thing is that a lot of cuDF's UDF tests are more about checking the results compatibility with pandas rather than flexing additional parts of numba's extension API, some of them are just a bit redundant in this context. For instance I don't think it string.upper and string.lower test different parts of numba as much as they test different parts of cuDF.

[gmarkall]

It's an option, but I believe there are some tradeoffs here. If we always clone main, there's a good chance our CI is broken whenever cuDF's CI is broken. We could avoid this by checking out a static commit or release, but I think that might be something we'd need to keep up to date manually.

I think keeping track with the latest release sounds good. I would be happy with us manually updating it since there's a release every two months, and it needn't be time critical to update it. Trying to use cuDF main does seem likely to introduce noise and churn for us. I envisage for now we could pip install cuDF 25.06 and check out the v25.06 tag to run the corresponding tests.

The other thing is that a lot of cuDF's UDF tests are more about checking the results compatibility with pandas rather than flexing additional parts of numba's extension API, some of them are just a bit redundant in this context. For instance I don't think it string.upper and string.lower test different parts of numba as much as they test different parts of cuDF.

I think they do compile a lot of functions to run a larger number of tests with different types though. I expect that to be more likely to catch edge cases and intermittent errors in the presence of using the extension APIs, so although it wouldn't be widening the surface area of API usage necessarily, I think it would be stressing the Numba-CUDA infrastructure more than just a small number of tests in our own test suite does - I think this is exactly what I want to get out of having the cuDF UDF tests run.

[brandon-b-miller]

/ok to test

[brandon-b-miller]

/ok to test

[brandon-b-miller]

/ok to test

[brandon-b-miller]

/ok to test