Only import BlazingSQL as necessary

[esoha-nvidia]

BlazingSQL is broken: BlazingDB/blazingsql#1037

This workaround allows the repo to work when BlazingSQL isn't enabled.

[esoha-nvidia]

Any progress here?

[ayushdg]

The existing change looks good.
Another additional case where blazingsql is imported would be here: https://github.com/rapidsai/tpcx-bb/blob/53b1eb2546e83a0e4a8e8937ddb56c2aaf0c3c33/tpcx_bb/xbb_tools/cluster_startup.py#L169

Called from
https://github.com/rapidsai/tpcx-bb/blob/main/tpcx_bb/benchmark_runner.py#L31
and
https://github.com/rapidsai/tpcx-bb/blob/main/tpcx_bb/benchmark_runner.py#L46

It would be great to handle that case as well to ensure the benchmark can be run without the presence of blazinsql in the existing environment.

[esoha-nvidia]

It would be great to handle that case as well to ensure the benchmark can be run without the presence of blazinsql in the existing environment.

I agree, but that change can be made separately from this one. It's better practice to have smaller commits that do just one thing each rather than one big commit which will be harder to revert if a revert is needed. As suggested here: https://softwareengineering.stackexchange.com/a/206984

So how about we submit this one and then do more in another one?

[beckernick]

I agree, but that change can be made separately from this one. It's better practice to have smaller commits that do just one thing each rather than one big commit which will be harder to revert if a revert is needed. As suggested here: https://softwareengineering.stackexchange.com/a/206984

If the premise of the PR is "to make blazingSQL optional" the suggested change is necessary. It doesn't make this PR less atomic to include a necessary change to accomplish the goal. With that said, a follow-up is fine.

[esoha-nvidia]

Would it even be possible to fix the other one? We can only do it at runtime. Does that code run after we already know if blazingsql will be used or not?

[beckernick]

Python will throw an ImportError or ModuleNotFoundError if it's not available, which could be caught as an exception and skipped at runtime.

Alternatively, I believe that code only exists due to a period in the spring/summer in which the ordering of imports of RAPIDS libraries was critical to avoiding some subtle errors. I suspect this might no longer be necessary, in which case it could be ripped out.

EDIT: As @ayushdg pointed out offline, it was actually to avoid long import times with the interaction between cuml and UCX.

[ayushdg]

Approving existing changes, the rest can be handled in a followup Pr. Will raise an issue for tracking.