Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upChanges after revdep checks of dplyr 0.8.0 RC #223
Conversation
`n()`, and `row_number()` no longer get special treatment, and should be imported, or prefixed too, as of dplyr 0.8.0
|
For reference:
|
|
I believe the error is spurious |
|
Thanks for this, @romainfrancois ! I'll take a look on my machine and try and work out those errors. Thanks for finding that issue with class vs attributes - I had sort of equated the two in my head, need to read up on the differences. |
|
In short the class is one attribute |
|
That actually really helps trigger my understanding of this, I know what I'm looking for to learn more about this now, thanks! :) |
|
OK so I get no errors on my machine, although I did only submit a patch release a few weeks ago, so I might try and include this in the next release for 0.5.0 around the end of Jan. |
This fixes two problems that were identified as part of reverse dependency checks of dplyr 0.8.0 release candidate. https://github.com/tidyverse/dplyr/blob/revdep_dplyr_0_8_0_RC/revdep/problems.md#naniar
n()must be imported or prefixed like any other function. In the PR, I've changed1:n()todplyr::row_number()asnaniarseems to prefix alldplyrfunctions.update_shadowwas only restoring the class attributes, changed so that it restores all attributes, this was causing problems when data was a grouped_df. This likely was a problem before too, but dplyr 0.8.0 is stricter about what is a grouped data frame.