Работа с преднамеренными конфликтами NAMESPACE - PullRequest
0 голосов
/ 06 сентября 2018

Я пишу пакет, который импортирует (и использует) как SparkR::sql, так и dbplyr::sql. Другие релевантные вопросы включают непреднамеренные столкновения, которые привели к моей случайности import ing.

В моем NAMESPACE есть:

importFrom(dbplyr, sql)
importFrom(SparkR, sql)

Обе эти функции используются в скрипте, и, зная о конфликте, я всегда буду указывать префикс имени пакета:

dbplyr::sql(...)
SparkR::sql(...)

Тем не менее, я получаю предупреждение о замене импорта при сборке / проверке пакета:

Предупреждение: замена предыдущего импорта «dbplyr :: sql» на «SparkR :: sql» при загрузке «my_pkg»

Что я вижу в Написание расширений R выглядит следующим образом:

Если пакету требуется всего несколько объектов из другого пакета, он может использовать в коде полностью квалифицированную ссылку на переменную [foo::f] вместо формального импорта ... Это немного менее эффективно, чем формальный импорт, а также теряет преимущество записи всех зависимостей в файле NAMESPACE (но их все равно необходимо записать в файл DESCRIPTION). Оценка foo::f приведет к тому, что пакет foo будет загружен, но не присоединен, если он еще не был загружен - это может быть преимуществом в задержке загрузки редко используемого пакета.

Прав ли я, что вывод этой / лучшей практики заключается в следующем:

  • Выберите, какая функция используется чаще всего, и добавьте ее к importFrom
  • Удалите «менее частую» функцию из importFrom, но сохраните этот пакет в DESCRIPTION
  • Просто используйте :: (возможно, перед require()) для «менее частой» функции

1 Ответ

0 голосов
/ 06 сентября 2018

Я всегда следовал этому совету :

Обычно пакеты указываются в разделе «Импорт» в ОПИСАНИИ, но не в NAMESPACE. Фактически, это то, что я рекомендую: перечислить пакет в DESCRIPTION, чтобы он был установлен, а затем всегда ссылаться на него явно с помощью pkg :: fun ().

В вашем случае:

  • Удалить оба importFrom
  • Храните оба пакета в Imports:
  • Используйте dbplyr::sql и SparkR::sql

Моя основная мотивация здесь - последовательность: даже без каких-либо конфликтов имен я всегда хочу использовать полное имя, чтобы было понятно, когда читает код , откуда взята какая-то функция. Если я не использую importForm и забуду об использовании полного имени в одном месте, R CMD ckeck поймает это. Я ценю эту ясность кода выше, чем (предполагаемое) преимущество сбора зависимостей в двух местах: ОПИСАНИЕ и (более явно) NAMESPACE.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...