Лучшее объяснение того, когда использовать импорт / зависимость

В руководстве « Writing R Extensions » содержатся следующие рекомендации о том, когда использовать импорт или зависимость:

Общие правила

• Пакеты, чье пространство имен требуется только для загрузки пакета с использованием библиотеки (pkgname), должны быть указаны в поле «Импорт», а не в поле «Зависит».
• Пакеты, которые необходимо подключить для успешной загрузки пакета с использованием библиотеки (pkgname), должны быть указаны только в поле «Зависит».

Может кто-нибудь дать немного больше ясности по этому поводу? Как я могу узнать, когда мой пакет нуждается только в загруженных пространствах имен по сравнению с тем, когда мне нужно присоединить пакет? Каковы примеры обоих? Я думаю, что типичный пакет - это просто набор функций, которые иногда вызывают функции в других пакетах (где некоторая часть работы уже была закодирована). Этот сценарий 1 или 2 выше?

редактировать

Я написал сообщение в блоге с разделом по этой конкретной теме (поиск «Imports v Depends»). Визуальные эффекты облегчают понимание.

"Imports"безопаснее, чем "Depends"(а также делает пакет, использующий его, «лучшим гражданином» по сравнению с другими пакетами, которые его используют "Depends").

А "Depends"директива попытка гарантировать , что функция из другого пакета можно, прикрепив другой пакет к основному пути поиска (то есть список сред , возвращенных search()). Эта стратегия, однако, может быть сорвана, если другой пакет, загруженный позже, поместит функцию с одинаковым именем ранее в путь поиска. Камеры ( в соде ) использует пример функции "gam", которая находится в обоих gamи mgcvпакетах. Если были загружены два других пакета, один из которых зависит, gamа другой mgcv- от функции, найденной вызовами, gam()будет зависеть от порядка, в котором они были присоединены эти два пакета. Не хорошо.

"Imports"Директива должна быть использована для любого поддерживающего пакета, функции которого должны быть помещены в <imports:packageName>(поиск сразу после <namespace:packageName>), а не на регулярной пути поиска. Если какой-либо из пакетов в приведенном выше примере использует "Imports"механизм (который также требует importили importFromдирективы в NAMESPACEфайле), ситуация может быть улучшена двумя способами. (1) Пакет сам получит контроль над тем, какая mgcvфункция используется. (2) Если очистить основной путь поиска от импортированных объектов, это даже не нарушит зависимость другого пакета от другой mgcvфункции.

Вот почему использование пространств имен является такой хорошей практикой, почему теперь оно обеспечивается CRAN, и (в частности) почему использование "Imports"безопаснее, чем использование "Depends".

Отредактировано, чтобы добавить важное предупреждение:

К сожалению, из приведенного выше совета есть одно общее исключение: если ваш пакет основан на пакете, Aкоторый сам находится "Depends"в другом пакете B, ваш пакет, вероятно, необходимо будет прикрепить Aс помощью "Dependsдирективы.

Это потому, что функции в пакете Aбыли написаны с ожиданием, что пакет Bи его функции будут присоединены к search()пути .

"Depends"Директива будет загружать и приложить пакет A, в котором точки пакета A«s собственная "Depends"будет, в цепной реакции, потому что пакет директива Bдолжна быть загружен и прилагается также. Функции в пакете Aсмогут найти функции в пакете, Bна которые они полагаются.

"Imports"Директива будет загружаться , но не приложить пакет Aи будет ни груз , ни присоединять пакет B. (в "Imports"конце концов, ожидается, что разработчики пакетов используют механизм пространства имен, и этот пакет Aбудет использовать "Imports"для указания на любые функции, к Bкоторым ему необходим доступ.) Вызовы вашими функциями для любых функций в пакете, Aкоторые полагаются на функции в пакете B, следовательно потерпеть неудачу.

Единственные два решения:

1. Сделайте, чтобы ваш пакет приложил пакет, Aиспользуя "Depends"директиву
2. Лучше, в конце концов, связаться с сопровождающим пакета Aи попросить их сделать более осторожную работу по созданию своего пространства имен (по словам Мартина Моргана в этом связанном ответе ).

Хэдли Уикхем дает простое объяснение ( http://r-pkgs.had.co.nz/namespace.html ):

Перечисление пакета в один Dependsили Importsгарантирует его установку при необходимости. Основное отличие заключается в том, что, где Importsпросто загружается пакет, Dependsприкрепляется его. Других различий нет. [...]

Если нет веской причины, вы должны всегда указывать пакеты Importsне Depends. Это потому, что хороший пакет является автономным и сводит к минимуму изменения в глобальной среде (включая путь поиска). Единственное исключение - если ваш пакет предназначен для использования в сочетании с другим пакетом. Например, аналог пакета основывается на вегане. Это бесполезно без вегана, поэтому Dependsвместо него есть веган Imports. Точно так же ggplot2 должен действительно зависеть от масштабов, а не импортировать его.

Камеры в SfDA говорят, что следует использовать «Imports», когда этот пакет использует механизм «пространства имен», и поскольку теперь все пакеты должны иметь их, тогда ответом может быть всегда использование «Imports». В прошлом пакеты можно было загружать, не имея фактически пространства имен, и в этом случае вам нужно было бы использовать Зависит.

Вот простой вопрос, который поможет вам решить, какой из них использовать:

Требует ли ваш пакет, чтобы конечный пользователь имел прямой доступ к функциям другого пакета?

• НЕТ -> Импорт (наиболее распространенный ответ)
• ДА -> Зависит

Единственный раз, когда вы должны использовать «Зависит», это когда ваш пакет является дополнением или компаньоном к другому пакету, когда ваш конечный пользователь будет использовать функции из вашего пакета и пакета «Зависит» в своем коде. Если ваш конечный пользователь будет взаимодействовать только с вашими функциями, а другой пакет будет выполнять только скрытую работу, используйте вместо этого «Импорт».

Предостережение в том, что если вы добавляете пакет в 'Imports', как обычно, ваш код должен будет ссылаться на функции из этого пакета, используя полный синтаксис пространства имен, например dplyr::mutate(), вместо just mutate(). Это делает код немного неудобнее для чтения, но это небольшая цена за лучшую гигиену упаковки.