Fix pylibcudf to_arrow with multiple nested data types

[mroeschke]

Description

Fixes the following case

In [25]: import pyarrow as pa, pylibcudf as plc

In [26]: pa_array = pa.array([[{"a": 1}]])

In [27]: pa_array.type
Out[27]: ListType(list<item: struct<a: int64>>)

In [28]: plc_table = plc.Table([plc.interop.from_arrow(pa_array)])

In [29]: plc.interop.to_arrow(plc_table)
RuntimeError: CUDF failure at: cpp/src/interop/to_arrow_schema.cpp:146: Number of field names and number of children doesn't match

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[mroeschke]

I'm not sure what metadata is here but I suspect this could use the same treatment? cc @vyasr

[galipremsagar]

I think it is Arrow metadata. Can we change this into if/else block? Like:

if metadata is None:
        metadata = [_maybe_create_nested_column_metadata(col) for col in tbl.columns()]
else:
        metadata = [_maybe_create_nested_column_metadata(m) if isinstance(m, str) else m for m in metadata]

[mroeschke]

Ah thanks. Changed it to use this if/else

[mroeschke]

So this didn't end up working.

From test_quantiles.py, the current invocation of pylibcudf.interop.to_arrow with a pylibcudf.Table involves metadata being the associated column names (i.e. list of strings) so I suppose the prior usage was OK

[vyasr]

Ugh I'm sorry, too many notifications. I missed this one.

Yes, the metadata is an instance of https://github.com/vyasr/cudf/blob/chore/update_ci_jobs/cpp/include/cudf/interop.hpp#L104, which we expose in Python here. I'm not sure if the question here is still relevant, but in general the reason that we need this parameter is to handle nested struct names. Almost every other form of metadata passed this way is redundant. I'll be working to get rid of this in the future using pyarrow APIs if possible so that we have parameter-free conversion to/from arrow.

[mroeschke]

No worries. I think in regards to this change there shouldn't be any modifications needed based on your answer

[mroeschke]

/merge