Closed rdboyes closed 1 year ago
Not sure how much of the functionality of pivot_longer
and pivot_wider
is needed before they're useful - wanted to check in on the general approach before implementing too many options. In particular, is this how you want to handle processing arguments? Or was there another way already implemented that I didn't catch
This looks amazing. Having glanced through your implementation, I think you've got the right approach.
The parse_args()
function actually does a very similar thing to parse_join_by()
except that the options for pivoting are a bit more constrained than for joins. I would suggest renaming the parse_args()
function to parse_pivot_args()
and this should be good to go. I may add support for interpolation to it but it's not critical for the initial implementation.
Also, thanks for adding the ability to run doctests locally. That in and of itself will hugely improve the development workflow.
The only other addition will be to add a page to the documentation page dedicated to pivoting. You're welcome to do it, but others can also help if you'd like.
Renaming done - I might wait on a full documentation page just because a lot of the more practical examples (e.g. something resembling https://tidyr.tidyverse.org/articles/pivot.html) will require additional options to be implemented first
Perfect. I'll put together a basic docs page and then plan to get this merged tonight.
Yeah, as a next step we can implement names_to
and values_to
. I don't think we necessarily need to implement all the bells and whistles, and certainly not yet.
adds pivot_longer with support for one argument (cols) and pivot_wider with support for (names_from, values_from). Also cleans up runtests.jl to allow doctests to easily be run locally using
] test