Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
%>% overlaps with pipe operator from magrittr #87
The problem is that if stringi is loaded after magrittr (which is likely because it's the more specialized package) it ends up with the higher priority.
Now your usage might even be older but with dplyr, ggvis and whole bunch of other packages going with magrittr that makes stringi more and more of a liability. You said yourself that stringi has alternatives, so couldn't you just remove the
I like stringi because it makes string handling in R a lot less aggravating but you're just the less general purpose package.
There is another solution for this problem. Let's be honest -
library("magrittr") "a"%>%"b" ## Error in "a" %>% "b" : RHS should be a symbol, a call, or a function. # from R doc for library function: # if you want to mask as little as possible, use > library(stringi,pos = "package:base") Attaching package: ‘stringi’ The following object is masked _by_ ‘package:magrittr’: %>% "a"%>%"b" ## Error in "a" %>% "b" : RHS should be a symbol, a call, or a function.
as you can see, our package did not mask operator from
I did an experiment over the last few days with a few of our users and that solution simply does not work for average users. The bugs are too subtle and reordering the search path after they've loaded stringi "the wrong way" is too advanced. There is simply no way I can recommend stringi for our in-house work let alone for our customers if that is the "solution", I'm sorry. :(
And we don't use any other package that implement