-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes after revdep checks of dplyr 0.8.0 RC #223
Changes 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()
asnaniar
seems to prefix alldplyr
functions.update_shadow
was 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.