Почему и когда создается пакет R?

Я понимаю, что этот вопрос довольно широкий, но мне интересно, какими должны быть решающие моменты при принятии решения о создании (или нет) нового пакета для R. Чтобы быть более конкретным, я бы добавил, что вопрос не о причинах используйте R сам по себе, больше о решении компилировать различные скрипты и интегрировать их в новый пакет

Среди вопросов, которые могут привести к этим решениям, я подумал (совершенно не исчерпывающим образом) о:

• отсутствие других пакетов в том же подполе;
• необходимость обмена с другими исследователями и обеспечения воспроизводимости экспериментов;

И среди моментов, которые могут привести к противоположному решению:

• часть используемых методов уже присутствует в некоторых других пакетах;
• Количество новых функций недостаточно для обоснования создания нового независимого пакета.

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

Я не программирую на R, но я программирую иначе, и здесь я не вижу проблем, специфичных для R.

Я предполагаю, что большинство людей сначала что-то пишут, потому что они действительно хотят этого для себя. И наоборот, любое чувство, что кто-то должен публиковать программное обеспечение, потому что это то, что нужно делать, должно решительно сопротивляться. Умные люди могут быть паршивыми программистами, и часто так и есть.

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

Если вы сомневаетесь, не публикуйте. Во многих сообществах существует проблема контроля качества посредственного или ошибочного программного обеспечения, выпущенного некритическими или неопытными программистами, хотя насколько серьезной является проблема, остается открытым для обсуждения. Оптимисты считают, что пустяки можно просто игнорировать и что пользователи будут достаточно быстро выявлять ошибки и ограничения; Пессимисты чувствуют, что мы тонем в некачественных вещах, и трудно отличить победителей от проигравших. (С другой стороны, опыт, полученный от публикации, является частью того, что позволяет программистам улучшаться.)

Об этом может быть книга, но на ум приходят несколько указателей:

1. Качественная документация отличает хорошее программное обеспечение и хороший код, иногда даже более очевидный. Никогда не стоит недооценивать, сколько работы потребуется для предоставления документации, которой заслуживает код. Программисты R часто требуют, чтобы пользователи R знали столько же, сколько они знают о внедряемой технике, и минимально документировали…

2. По мере возможности тестируйте свой код, чтобы вы могли воспроизводить опубликованные решения с реальными данными из других источников. (Если вы кодируете что-то совершенно новое, это может быть более трудным, но не невозможным. Кроме того, вы часто задаетесь вопросом, является ли это их ошибкой или вашей.)

3. Программисты часто недооценивают способность пользователей бросать неподходящие данные в программу. Итак, подумайте о том, что может пойти не так, например, с пропущенными значениями, нулями, если программа предполагает положительный результат, и т. Д. И т. Д. (В этом случае задача пользователей - найти проблемы и улучшить код с помощью обратной связи. , но легко ломающаяся программа не улучшит вашу репутацию.)

Это важный и практический вопрос. Давайте начнем с того, что будем различать написание пакета и его публикацию в CRAN.

Причины не писать пакет:

• Эффективность затрат.
• Недостаток опыта.

Причины, чтобы написать пакет R:

• Поделиться с людьми и платформами.
• Форсирует аккуратный код и рабочий процесс.
• Простота использования (даже для себя), когда функции начинают накапливаться.

Причины для отправки пакета (CRAN, Bioconductor, ...):

• Вклад в сообщество.
• Легкость распространения.

Помните, что есть вариант № 3; Вы можете попросить сопровождающего соответствующего пакета включить ваш код или данные.

Мои личные триггеры для упаковки:

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

• Коллега просит у меня код. Существенная часть кода, который я пишу, по крайней мере, столько же по запросу коллег (которые используют R, но сами не программируют), чем для себя.

• Я использую формальные требования пакета (документации), чтобы «заставить» меня очистить и документировать мой код.

Я согласен с @JohnRos, что существует большая разница между написанием пакета и его публикацией.

• Я обычно упаковываю вещи рано, но потом делаю упаковку только «полупубликой». То есть он может быть доступен на внутреннем сервере (или на r-forge), поэтому мои коллеги могут получить доступ к пакету. Но я публикую в CRAN только после того, как пакет использовался близкими коллегами в течение нескольких месяцев или даже нескольких лет. Это не поднимает все ошибки в соответствии с пунктом № 3 @Nick Cox, но изрядное их количество.
  Версии пакета (я поставил дату после тире в номере версии) позволяют легко что-то исправить («чтобы сделать это и то, убедитесь, что вы введете хотя бы версию прошлой недели»)

• Согласно моему рабочему контракту, мой работодатель имеет последнее слово при принятии решения о том, можно ли и как опубликовать пакет во внешнем мире.

Дело в том, где я не еще есть стратегия хорошо для упаковки данных.

Комментарии к вашему списку причин:

• отсутствие других пакетов в том же подполе;

Отсутствие пакета, который делает то, что мне нужно, вызывает написание кода, но это не имеет отношения к решению, упаковывать или нет.

• необходимость обмена с другими исследователями и обеспечения воспроизводимости экспериментов;

Определённо. Возможно, уже нужно делить между несколькими компьютерами, которые я использую.

И среди моментов, которые могут привести к противоположному решению:

• часть используемых методов уже присутствует в некоторых других пакетах;

Вы могли бы импортировать эти методы в свой пакет / код: это противоречит написанию такого кода, но только косвенно связано с упаковкой.

• Количество новых функций недостаточно для обоснования создания нового независимого пакета.

Для меня нет минимального количества функций для запуска пакета. По моему опыту, пакеты имеют тенденцию расти «автоматически». Напротив, после того, как я несколько раз обнаружил, что разветвляю новый пакет из другого (потому что, например, некоторые вспомогательные функции, в конце концов, оказались тематически разными и полезными и в других ситуациях), я теперь довольно создание новых пакетов немедленно.

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

Я бы сказал, создайте пакет всякий раз, когда вы выполняете достаточно большой набор похожих задач в R, чтобы вы могли воспользоваться пакетом, в котором вы можете помещать вещи в пространство имен (чтобы избежать конфликтов с функциями с одинаковыми именами), куда вы можете написать документация. У меня даже есть пакет на GitHub для связывания множества функций, которые не связаны, но я использую так часто, что я думал, что они заслуживают документацию, файлы man и т. Д.

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

Три инструмента, которые я бы сказал, важны:

• devtools pkg , чтобы упростить сборку пакетов (см. также вики на страницах devtools github)
• roxygen2 pkg , чтобы упростить написание документации для вашего пакета
• GitHub, Вы можете использовать install_github(или аналогично install_bitbucket и т. Д.) Для установки непосредственно из GitHub, который удобен для совместного использования с другими.

Я согласен со всем, что я прочитал до сих пор. Все эти причины являются хорошей практикой программирования и не относятся к R в частности. Однако большую часть времени я пишу пакеты R, и по еще одной причине. Поэтому я добавлю:

R-конкретная причина, чтобы написать пакет R:

• потому что ты пишешь на С

Каждый раз, когда вы используете иностранные языки, такие как C, C ++ или FORTRAN (в основном для высокопроизводительных вычислений), написание пакета в значительной степени стоит проблем. Если у вас есть более одной или двух функций, вы быстро получите файлы повсюду и зависимости между кодом R и C, которые сложно поддерживать и переносить.

Одна причина, не упомянутая в других отличных ответах: у вас большой или сложный проект анализа данных. Упаковка, вначале, данных в виде пакета, а затем расширение с помощью полезных функций для преобразования, построения графика или вычисления конкретного анализа. Таким образом, вы получите документированную версию данных со всеми функциями, используемыми для расчета анализа, представленного в отчете. Тогда отчет (ы) из проекта может быть написан с использованием knitr или других пакетов для воспроизводимых исследований!

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