Best practices when extending dplyr?

I am thinking not so much about programming with dplyr or about the various translation from dplyr to other formats (e.g. as in dbplyr, dtplyr, etc.) but more about modifying existing dplyr verbs or writing new related functions that are designed for use in or in conjunction with dplyr. For example as in tidylog and dplyover.

Best practices on how developers should go about extending dplyr functionality (or related plans for the future)?

2 Likes

As a little context, I'd opened a previous topic on doing pairwise operations in dplyr which turned into the package pwiser. pwiser is just a slight modification on dplyr::across() so I'd hoped it would "just work" with dbplyr, and the other dplyr backends, but this turned out not to be the case (brshallo/pwiser#8). However I'd wondered to myself whether there were some "best practices" I could/should have followed that would have come with this benefit of having pwiser work with backends "out of the box" (or with minimal additional effort) along with other benefits, like being more robust to potential future updates to dplyr (that I'm sure pwiser is vulnerable to).

P.s. I am not actively developing pwiser as dplyover can do the same thing and much more.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.