Предстоящие NAMESPACE, зависит, Импорт изменений для 2.14.0 (некоторые определения/использование пожалуйста)

Если вы автор пакета, вы, надеюсь, хорошо осведомлены о предстоящих изменениях в структуре пакета, когда мы переходим к 2.14 примерно через неделю. Одно из изменений заключается в том, что для всех пакетов потребуется NAMESPACE, и один будет создан для вас в случае, если вы его не создадите (эквивалент R ваших прав на Miranda в США). Поэтому, будучи хорошим гражданином, я пытался понять это. Вот раздел из R-exts:

1.6.5 Резюме - преобразование существующего пакета

Подводя итог, преобразование существующего пакета для использования пространства имен включает в себя несколько простых шагов:

Определите общедоступные определения и поместите их в директивы экспорта. Определите определения метода в стиле S3 и напишите соответствующий метод S3 деклараций. Определите зависимости и замените любые требуемые вызовы на импортировать директивы (и внести соответствующие изменения в Зависимости и Импортирует поля файла DESCRIPTION). Заменить функции .First.lib с функциями .onLoad или useDynLib.

Чтобы я сделал правильные вещи здесь, может кто-то дать короткое четкое определение/ответ (я нарушаю правило, имея несколько небольших, но связанных вопросов?). Все ответы должны учитываться в 2.14, пожалуйста:

Определение NAMESPACE, используемое R
Есть ли способ создать NAMESPACE перед сборкой и проверкой, или мы будем использовать b/c один раз, а затем автоматически отредактируем NAMESPACE?
Разница между "Зависит:" и "Импорт:" в файле ОПИСАНИЕ. В частности, почему я помещал пакет в "Зависит:" вместо "Импорт:" или наоборот?
Похоже, что "require" больше не используется, хотя он этого не говорит. Это правильная интерпретация?

Спасибо!

Ответ 1

Я написал немного на эту тему в https://github.com/hadley/devtools/wiki/Namespaces.

Чтобы ответить на ваши вопросы:

См. ответ Dirk.
Использовать roxygen2
Теперь, когда у каждого пакета есть пространство имен, нет причин использовать Depends.
require следует использовать только для загрузки предлагаемых пакетов

Ответ 2

У пакетов CRAN были NAMESPACE, так как почти бессмертный. Просто выберите несколько из ваших любимых пакетов CRAN и посмотрите их файлы NAMESPACE.

Это может быть так же просто, как этот однострочный (плюс комментарий), взятый из snow:

# Export all names unless they start with a dot
exportPattern("^[^.]")

Запустите R CMD check, как обычно, и вы должны быть в порядке в большинстве случаев.

Ответ 3

Я собираюсь ответить на свой вопрос несколькими подробностями, которые я узнал после переключения нескольких пакетов на R 2.14.

В приведенном выше описании из ручного типа создается впечатление, что все, что у вас было в зависимости от: для R 2.13, должно быть перенесено в "Импорт": в R 2.14. Вы должны это сделать, но они не являются 1-для-1 функционально одинаковыми, поскольку я надеюсь, что это будет ясно из примечаний ниже.

Здесь мы идем:

Зависит: вероятно, следует использовать только для ограничений на версии, такие как "R >= 2.10" или "MASS > 0,1", и ничего больше не под R 2.14.

Наличие пространства имен частично является механизмом уведомления пользователей о том, что могут быть конфликты имен и "замены" - другими словами, переписывание используемых имен. Файл NAMESPACE должен совпадать в пунктах и в поле Импорт: ОПИСАНИЕ. Введенные имена функций и т.д. Будут перечислены в разделе "загружено через пространство имен (и не подключено)" в sessionInfo(). Эти пакеты установлены, но не загружаются (т.е. Нет библиотеки (некоторые импортированные пакеты)).

Другая роль пространства имен заключается в том, чтобы сделать функции доступными для вашего пакета "внутренне". Под этим я подразумеваю, что если ваш пакет использует функцию в импортированном пакете, он будет найден.

Однако, когда у вас есть пример в файле .Rd, который будет запускаться во время проверки, пакеты, которые вы использовали в Depends: in R 2.13, но теперь находятся в Импортировании: под R 2.14 недоступны. Это связано с тем, что среда проверки в значительной степени похожа на поиск script в чистой среде (при условии, что вы используете R -vanilla, поэтому .Rprofiles и т.д. Не были запущены). Если вы не поместили в свой пример инструкцию для библиотеки (нужного пакета), она не будет работать под R 2.14, даже если она была в разделе R 2.13. Поэтому старые примеры не обязательно запускаются, хотя ваш пакет Imports: необходимые пакеты, потому что снова Импорт: не совсем то же самое, что и Depends: (строго, они прикреплены, но не загружены).

Пожалуйста, поправьте меня, если это не так. Большое спасибо Хэдли Уикхэму и другим, которые помогли мне!

Ответ 4

Недавно я работал над этим для одного из моих пакетов. Вот мои новые линии "Зависимости", "Импорт" и "Предлагает"

Depends: R (>= 2.15.0)
Imports: nlme, mvtnorm, KFAS (>= 0.9.11), stats, utils, graphics
Suggests: Hmisc, maps, xtable, stringr

статистика, утилиты и графика являются частью базы R, но пользователь может их отделить, а затем мой пакет не будет работать. Если вы используете R из командной строки, вы можете подумать: "Почему бы кто-нибудь их отделить?". Но если пользователь использует RStudio, скажем, я видел, как они просматривают и "откручивают" все пакеты. Тем не менее, я не хочу, чтобы мой пакет переставал работать, если они это делают. Или они могут переопределить, скажем, функцию графика (или некоторую другую функцию), а затем мой пакет завершится с ошибкой.

Мой NAMESPACE имеет следующие строки

import(KFAS)
import(stats)
import(utils)
import(graphics)

Я не хочу проходить и отслеживать, какие статистики, утилиты и графические функции я использую, поэтому я импортирую их все пространства имен. Для KFAS мне нужны только две функции, но имена экспортируемых функций изменяются между версиями, поэтому я импортирую все пространство имен, а затем в свой тест кода, какая версия имеет пользователь.

Для mvtnorm и nlme я использую только одну функцию, поэтому я импортирую только те. Я мог бы импортировать все пространство имен, но попытаюсь импортировать только то, что я действительно использую.

importFrom(mvtnorm, rmvnorm)
importFrom(nlme, fdHess)

Виньетки, в которых появляются пакеты Offersests, имеют

require(package)

в них.

Для экспортируемых функций в моей NAMESPACE я немного разорван. CRAN стал строгим, не допуская: в вашем коде пакета. Это означает, что если я не экспортирую функцию, я ограничу творческое повторное использование. С другой стороны, я понимаю необходимость только экспортировать функции, которые вы намерены поддерживать с помощью стабильного списка arg и вывода, иначе мы сломаем друг друга пакетами, изменив интерфейс функции.