Remove build_struct|list_column

[mroeschke]

Description

IMO these do not provide much value compared to constructing with ListColumn or StructColumn cc #14778 (comment)

Checklist

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

[isVoid]

Since these APIs are also used in cuspatial, would you mind making a PR to cuSpatial replacing these uses?

[mroeschke]

Since these APIs are also used in cuspatial, would you mind making a PR to cuSpatial replacing these uses?

@isVoid sure opened a PR in cuspatial: rapidsai/cuspatial#1327

[davidwendt]

Based on #14786 (review) should this be considered a breaking change?

[mroeschke]

I think this is considered a private API since it's in the cudf.core Python namespace, but I'll label it as breaking anyways

[isVoid]

Based on #14786 (review) should this be considered a breaking change?

Actually no, I don't think this should be a breaking change. cuSpatial shouldn't use these internal APIs in the first place. We discussed about removing all of these usage. Labeling this as a breaking change can make contributors who reads the changelog mistakenly believe the column APIs are public.

[vyasr]

I agree with @isVoid, we shouldn't mark these as breaking. We should just remember while reviewing these sort of changes to cudf's column layer that they have the potential to break cuspatial in particular.

[mroeschke]

@vyasr any other project you can think of that might be using this API? I removed this API from cuspatial in rapidsai/cuspatial#1327

[vyasr]

Apologies, I missed this query earlier. No, I can't think of any other project using these APIs. Morpheus is the only other package that uses cudf internals, but they tend to use a different set of them (more focused on extracting pointers from columns and then reconstructing them, basically things around pybind/cython interop rather than creating cudf columns from more arbitrary data).

[vyasr]

/merge