Skip to content
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

n() no longer works if dplyr not attached #4062

Closed
JohnMount opened this issue Dec 31, 2018 · 9 comments

Comments

@JohnMount
Copy link

commented Dec 31, 2018

packageVersion("dplyr")
#> [1] '0.7.99.9000'

# fails 
dplyr::mutate(data.frame(x=1), count = n())
#> Error in n(): could not find function "n"

# works
dplyr::mutate(data.frame(x=1), count = dplyr::n())
#>   x count
#> 1 1     1

# works
library("dplyr")
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
dplyr::mutate(data.frame(x=1), count = n())
#>   x count
#> 1 1     1

Created on 2018-12-31 by the reprex package (v0.2.1)

I am filing this as requested in the email I received today, excerpted below.

This is an automated email to let you know that:

  • A new version of dplyr is ready to go to CRAN. dplyr is currently at version 0.7.8 and will become 0.8.0 upon release.
    If you have discovered a bug in dplyr, please file an issue (ideally with a small reprex that illustrates the problem) at

By my count ( https://github.com/tidyverse/dplyr/blob/master/revdep/problems.md ) this change breaks about 70 packages. Also it seems the proposed dplyr update is breaking about 120 of 705 dependent packages (about 17%).

@joranE

This comment has been minimized.

Copy link
Contributor

commented Dec 31, 2018

I believe this was intentional, e.g. #4030

@hadley

This comment has been minimized.

@hadley hadley closed this Dec 31, 2018

@JohnMount

This comment has been minimized.

Copy link
Author

commented Dec 31, 2018

The dplyr::n() fix does not work for database handles (filed as tidyverse/dbplyr#197 ).

packageVersion("dplyr")
#> [1] '0.7.8'

# works
dplyr::summarize(data.frame(x = 1), count = dplyr::n())
#>   count
#> 1     1

# fails
db <- DBI::dbConnect(RSQLite::SQLite(), ":memory:")
t <- dplyr::copy_to(db, data.frame(x = 1), "d")
dplyr::summarize(t, count = dplyr::n())
#> Error: This function should not be called directly

Created on 2018-12-31 by the reprex package (v0.2.1)

@JohnMount

This comment has been minimized.

Copy link
Author

commented Dec 31, 2018

Also the replyr package had the same issue, but this was not caught in the check. So there may be many more packages affected.

JohnMount added a commit to WinVector/seplyr that referenced this issue Dec 31, 2018
JohnMount added a commit to WinVector/replyr that referenced this issue Dec 31, 2018
@hadley

This comment has been minimized.

Copy link
Member

commented Dec 31, 2018

Yes, this is a breaking change that will affect code. We are doing it to make dplyr consistent with usual R semantics. As with all breaking changes, it causes some short term pain in return for pain reduction in the long term.

@yutannihilation

This comment has been minimized.

Copy link
Member

commented Dec 31, 2018

I agree this is worth breaking. It is error-prone to allow unqualified n() without attaching dplyr. For example:

n <- function() stop("foo")
dplyr::summarise(iris, n())
#> Warning: The `printer` argument is soft-deprecated as of rlang 0.3.0.
#> This warning is displayed once per session.
#> Error in summarise_impl(.data, dots): Evaluation error: foo.

Created on 2019-01-01 by the reprex package (v0.2.1)

Actually, I found #4030 when I was investigating the problem caused by the conflict between dplyr's n() and SparkR's n(), which took time to figure out what happened... So, I welcome this breaking change 👍

@lionel-

This comment has been minimized.

Copy link
Member

commented Jan 2, 2019

@yutannihilation If you install latest dev rlang, you shouldn't see these warnings about printer anymore. I have fixed a bug in the code that decides when to warn.

@yutannihilation

This comment has been minimized.

Copy link
Member

commented Jan 3, 2019

@lionel- Thanks, I'll try the dev version! (FYI: I haven't seen this warning with the dev version of dplyr. The reprex above was created with dplyr 0.7.8.)

@lock

This comment has been minimized.

Copy link

commented Jul 2, 2019

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.