Forward all_equal() to dplyr

[krlmlr]

Slightly different implementation than in dplyr causes trouble (tidyverse/dplyr#2264). Throw an error if dplyr is not installed.

[krlmlr]

@hadley: Do you see a problem if tibble tries to forward to dplyr::all_equal() and fails if dplyr is not installed?

[hadley]

Yeah, I think that's ok.

[hadley]

Alternatively, maybe we tibble simply shouldn't define an all.equal() method? Although I guess that means you'd get different behaviour depending on whether or not dplyr was loaded, which we want to avoid.

[krlmlr]

Oh, tibble does have its own implementation of all_equal(), but the implementation is slightly different; behavior depends if dplyr is loaded or not. We'd have to move half of dplyr's C++ code here to use the same implementation.

[jennybc]

Alternatively, maybe we tibble simply shouldn't define an all.equal() method? Although I guess that means you'd get different behaviour depending on whether or not dplyr was loaded, which we want to avoid.

I just experienced exactly this and it was mystifying.

In my case, dplyr is not explicitly loaded -- a deliberate choice, on my part -- and yet because I have assign("%>%", dplyr::%>%, envir = .__Rprofile.env__.) in my .Rprofile, dplyr is "loaded via a namespace (and not attached)", in the sessionInfo() sense. Obviously I need to rethink the wisdom of this line of .Rprofile!

But the result is that all.equal(tibble_1, tibble_2) is calling tibble::all.equal.tbl_df(), which forwards to dplyr::all_equal(), which apparently has different default behaviour around attributes. I am accustomed to a default of check.attributes = TRUE and expected my comparison to behave that way. But dplyr::all_equal() seems to act as if check.attributes = FALSE. Or maybe it's just oblivious to attributes.

Has this ever been considered? The tidyverse/dplyr style of tibble comparison only happens with all_equal() (with the underscore) and never silently with all.equal().

[jennybc]

Related: I believe this line in my .Rprofile is why it took me so long to sympathize with people reporting that tibble printing or indexing changed during the course of a script or interactive session, as more packages gradually got loaded. I always got tibble-style printing and indexing and therefore never personally experienced this behaviour.

[hadley]

Probably the safest thing to do is explicitly forward to dplyr, with a clear error if dplyr isn't installed.