add "Available methods" vignette

rstudio / bundle

Prepare objects for serialization with a consistent interface

https://rstudio.github.io/bundle/

Other

27 stars 4 forks source link

add "Available methods" vignette #33

Closed simonpcouch closed 2 years ago

simonpcouch commented 2 years ago

I found this a bit trickier than anticipated, both in terms of finding a table structure that's informative and doing so in an automatically extensible way.

Should ecosystem and package be merged, and "tidymodels" listed as the package? Thought ecosystem may be helpful with eventual introduction of mlr3.
Should this be joined with the analogous butcher/broom table?

Very much open to revision!🦥

For ease of review:

A screenshot of a vignette written in markdown. The document is titled 'Available bundling methods,' and includes a three column table with columns ecosystem, package, and class, detailing what model objects are currently supported by bundle. There are 13 rows, with 4 allotted to tidymodels-specific bundlers.

Closes #29. :)

juliasilge commented 2 years ago

This is looking good! 🙌

I have a question about what the best approach would be here. I see two main options:

Make an "enriched" table like what you have shown here, which requires us to check/edit this file when new bundling methods are added. This option should involve us adding at the least a release question to double check that we've done this.
Make a simpler table, more like what butcher has. This isn't as useful to less experienced folks, because this option requires that you know that, for example, train objects come from caret. It will always be correct and in sync with reality, though.

How confident are you that the first option is the best one? Also, I am not aware of a way for us to programmatically get the package that defines a class. Do you know of anything like this?

simonpcouch commented 2 years ago

How confident are you that the first option is the best one?

Not at all🏄

I would note with the second one, though, that that table would be n x 1 in the case of this package, and would be redundant with the current entries resulting from @family bundlers in help-pages. If option 2 feels good enough, I say we close this PR in favor of those entries rather than adding a vignette.

Also, I am not aware of a way for us to programmatically get the package that defines a class. Do you know of anything like this?

I'm not! Tossed this around for a bit and this feels like it'd be a really hard problem to solve. Would love if we could integrate that, though.

juliasilge commented 2 years ago

I set up the pkgdown site so we can see how clear the list of other bundlers looks to us.

juliasilge commented 2 years ago

I am now thinking that for this package (which isn't quite the same as butcher, with lots of different generics) the /reference page actually does a nice job of communicating what methods exist and what they are for. What do you think of using that to point folks to, for questions about what does/does not have support?

simonpcouch commented 2 years ago

Ah, that's a great point! Yes, I agree that /reference is a good place to point folks to. Thumbs up from me on closing this PR if that approach feels good to you.

juliasilge commented 2 years ago

Yes, let's go with that! 🙏