Это происходит со мной чаще, чем я должен признать. dplyr сталкивается с MASS::select
, plyr::summarise
и stats::filter
, в частности, при загрузке пакетов, которые загружают одну из этих библиотек через библиотеку (они не должны, но некоторые еще не работают), или когда вы загружаете dplyr в свой .Rprofile
(не надо!). И это может привести к довольно неясным проблемам, а не всегда сообщению об ошибке, особенно конфликтует с plyr
.
Я только недавно узнал о функции conflicts()
. Это полезно, но конфликты «over-reports», когда два пакета имеют одинаковые функции, например. tidyr :: %>%
и dplyr :: %>%
.
Так что я написал a function, чтобы сказать мне, сойду ли я с ума или на самом деле возникает конфликт, вызывающий текущую ошибку. Он не только проверяет наличие конфликтов, но проверяет, является ли определенный желаемый пакет «сверху» и действительно ли тела функции отличаются.
Он делает это для dplyr по умолчанию, но вы можете указать другой пакет, используя параметр want_package
. Например, у меня часто возникают проблемы с recode
и alpha
, которые повторно используются во многих пакетах.
Использование просто: amigoingmad()
.
По умолчанию, он будет также автоматически «исправить» вещи, если dplyr не является «сверху», используя следующие команды:
detach("package:dplyr", character.only = TRUE)
library("dplyr", character.only = TRUE)
Обратите внимание, что функция будет сообщать, если определенная пользователем функция блокировки dplyr, но не исправляет это автоматически для безопасности (просто удалите функцию в этом случае).
На данный момент это решение не вызвало у меня никаких проблем. Конечно, я бы не стал использовать это в производственном коде, но когда вы отлаживаете файл .Rmd
и, возможно, случайно испортили заказ на загрузку, это быстрый способ узнать.
Если вы хотите, чтобы это в пакете:
devtools::install_github("rubenarslan/formr")
Вы можете использовать его как вы только что написал: 'dplyr :: выберите (мили на галлон)' –