Support conversion to/from cudf in dask.dataframe.core.to_backend

[rjzamora]

Depends on dask/dask#9758

Description

This PR corresponds to the cudf component of dask/dask#9758

Checklist

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

[galipremsagar]

LGTM, minor comment.

[vyasr]

Is this critical? We're entering an already-delayed code freeze tonight, so it would be better to push this to 23.04.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (branch-23.04@fea6288). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files

@@               Coverage Diff               @@
##             branch-23.04   #12380   +/-   ##
===============================================
  Coverage                ?   85.85%           
===============================================
  Files                   ?      158           
  Lines                   ?    25204           
  Branches                ?        0           
===============================================
  Hits                    ?    21638           
  Misses                  ?     3566           
  Partials                ?        0           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[wence-]

FWIW, although I think that this is probably safe, it doesn't really feel like the right kind of change we should be attempting to get in in code freeze; so I'm with @vyasr here that I think this is better to slip to 23.04.

[wence-]

Perhaps this is a question for the dask side of the implementation, but under what circumstances can kwargs be non-empty (and then relatedly, are there circumstances in which we already have a cudf-backed collection where non-empty kwargs could semantically require something different than data.map_partitions(identity))?

[rjzamora]

Good question - I updated things a bit to be explicit about supported/unsupported key-word arguments. I also added a bit more test coverage.

Context: We (probably) do want to make it possible to do things like ddf.to_backend("cudf", nan_as_null=False). However, I'm still unsure of the best way to document the supported to_backend kwargs for the various conversions.

[wence-]

Hmmm, can we link to the registered backend dispatch function which could explain what it accepts as keyword arguments?

[rjzamora]

I’ll give this a think, but not sure how/where to link to the dispatch-function args, since the available arguments to the user-facing API (to_backend) will depend on the specified backend. Any ideas?

The base branch was changed.

[rjzamora]

FWIW, although I think that this is probably safe, it doesn't really feel like the right kind of change we should be attempting to get in in code freeze; so I'm with @vyasr here that I think this is better to slip to 23.04.

Thanks for the review @wence- ! Agree with you both that this should go in 23.04 - The Dask documentation can be updated pretty easily to specify that dask_cudf>23.02 will be required to use the to_backend API with gpu-backed DataFrame data.

[rjzamora]

/merge