Package Flight SQL

[lidavidm]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Enable the Flight SQL build. This doesn't have any additional dependencies.

[conda-forge-linter]

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.

[lidavidm]

Hmm, I'm going to have to debug that Windows issue (and figure out why our existing CI doesn't catch it). Do we prefer dropping Flight SQL from Windows and proceeding for now, or just holding off with this until 9.0.0 (assuming I get in a fix)?

[xhochy]

If the fix is small, we can also apply a patch on top of 8.0.0 here.

[lidavidm]

Looks like one build flaked. I disabled it on Windows since it's nontrivial to fix (apache/arrow#13434)

[lidavidm]

Looks like some of the builds tend to time out (maybe adding Flight SQL is pushing us above the threshold) - wonder if there's some way to speed up the builds or trim things we don't need. I know some of the Arrow CI builds enable unity builds to try to speed things up, maybe that's worth trying here?

[kkraus14]

Looks like some of the builds tend to time out (maybe adding Flight SQL is pushing us above the threshold) - wonder if there's some way to speed up the builds or trim things we don't need. I know some of the Arrow CI builds enable unity builds to try to speed things up, maybe that's worth trying here?

I tried requeueing but we're hitting timeouts on emulated builds here. We should probably try to move towards cross compilation but that's a relatively big lift.

[jakirkham]

Unfortunately cross-compiling and CUDA builds don't work together today.

[kkraus14]

Unfortunately cross-compiling and CUDA builds don't work together today.

Doesn't that only apply to device code requiring nvcc? The arrow package just uses the CUDA driver API without any actual device code. We should be able to cross compile against a libcuda stub?

[jakirkham]

Which means we need to use the CUDA Docker images. This is part of the issue.

[kkraus14]

Any issues with merging this without all of the emulated builds passing? I can then babysit the merge commit jobs to make sure we get packages published.

[jakirkham]

None. Though it looks like we are down to one.

[kkraus14]

None. Though it looks like we are down to one.

Will give this a chance to finish its run, but if it fails lets merge.

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[lidavidm]

Thanks everyone!

[h-vetinari]

Unfortunately cross-compiling and CUDA builds don't work together today.

Doesn't that only apply to device code requiring nvcc? The arrow package just uses the CUDA driver API without any actual device code. We should be able to cross compile against a libcuda stub?

Which means we need to use the CUDA Docker images. This is part of the issue.

I think I figured out the images part (or at least the rendering part) in #859. Meaning we have x86 build compilers, but I don't yet know how we get the libcuda stub for host (aarch/ppc) into there. We might be able to download it in the build scripts...?

[kkraus14]

We might be able to download it in the build scripts...?

You're not allowed to redistribute a libcuda stub in a container unless the container was based on the nvidia/cuda container.

[h-vetinari]

You're not allowed to redistribute a libcuda stub in a container unless the container was based on the nvidia/cuda container.

I propose to continue the discussion in #859, if that's alright.