Является ли хорошей практикой часто обновлять пакеты R?

Question

Я начал использовать R некоторое время назад и не знаю, как часто обновлять установленные пакеты (в это время я использую в основном ggplot2 и погремушку). С одной стороны, это типичный импульс geek, чтобы иметь последнюю версию :-) С другой стороны, обновления могут нарушать функциональность и, как новичок R, я не хочу тратить время на изучение несовместимости пакетов и переустановку библиотек, это почти наверняка Я бы не заметил никакой разницы с улучшенным пакетом.

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

И чтобы быть ясным: я не говорю о самом R, а о его библиотеках.

Спасибо.

Answer 1

Вот моя философия: наивный пользователь никогда не обновляется. Усовершенствованный пользователь всегда обновляется. Пользователь питания часто обновляется, но осторожно.

Непрерывное обновление не всегда полезно. Ошибки работают в обновленных версиях R-библиотек (или самих R!), И вы можете сломать свой существующий код, обновив его, не читая журнал изменений или историю фиксации. Например, R 2.11 нарушил lme4 на OS X ... он платит, чтобы тщательно обновлять и запускать демонстрации пакетов между релизами. Это действительно отстойно обновляться до новой библиотеки или выпуска R и понимать, что что-то сломалось, когда у вас есть крайний срок.

Answer 2

Да, это так.

Почему именно вы хотите повесить на старые ошибки и недостающие функции?

Answer 3

Да, если у вас есть уважительная причина, чтобы не (см мой комментарий к Dirk)

Answer 4

вопрос уже ответил, но я предлагаю свои 2 цента. В организации обновление R следует рассматривать как обновление gcc или Java: с предупреждениями, с промежуточной областью, планом отката и т. Д. На работу и результаты других могут влиять. [См. Обновление # 2]

Я более импульсивен относительно обновления пакетов R. Пока вы можете воспроизвести состояние своей системы в любой момент времени, вам не о чем беспокоиться. Обеспечение того, чтобы ночные резервные копии возникали, должны быть доменом вашего sysadmin.

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

---

Update 1. Как уже отмечалось в комментариях и выше обновления в производственной среде или любой среде, где стабильность является оптимальной (например, ошибки, либо известны, либо не имеет значения), представляя новые ошибки, новые зависимости , различные выходные данные или любое другое регрессионное программное обеспечение, должны выполняться достаточно тщательно. Более того, там, где вы много обновляете. Обновление от R-Forge скорее всего подвергает вас новейшим ошибкам, чем от CRAN. Тем не менее, я нашел и сообщил о ошибках, которые сохранялись через 3+ версии пакета на CRAN, а также другие регрессии, которые только волшебным образом появились. Я много тестирую, но обновление, поиск новых ошибок и отладка - это усилия, которые я не всегда хочу (или успеваю) предпринять.

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

Обновление 2. В организации я должен сказать, что ответ отрицательный. Фактически, в любом случае, когда могут быть два или более одновременных экземпляра R, очень неразумно слепо обновлять пакеты, в то время как другой может их использовать. Вероятно, будут хорошие методы для hot-swapping packages, I just don't yet know them. Имейте в виду, что двум экземплярам нужны только общие библиотеки (например, где хранятся пакеты), и AFAIK не должны запускаться одновременно на одном компьютере. Таким образом, если библиотеки размещены в общих системах, например, над NFS, возможно, неизвестно, где еще работает R в то же время, используя эти библиотеки. Случайно убийство другого процесса R обычно не очень хорошо.

Answer 5

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

Но стоит подчеркнуть, что эти два поведения не являются исключительными. Можно установить разные версии R и поддерживать разные libraries, чтобы извлечь выгоду из среды разработки, связанной с кровотечением, и более стабильной для производства.

Надеюсь, это поможет.

Answer 6

Я бы хотел ответить так часто, как вам нужно, и никогда, когда вы спешите!

Во-первых, обсудите шансы, что вы работаете под ошибкой, о которой вы не знаете. Я бы решил, что это довольно редко. Если вы страдаете от ошибок, и есть более новая версия, в которой исправлена ​​ошибка, планируйте обновление. Если вы хотите новую функцию, планируйте обновление. Если это ваш первый день после Рождества, и самые большие накладные расходы пытаются запомнить то, что вы на самом деле делаете в последний раз, то накладные расходы на некоторые новые требования к зависимостям (которые могут включать компоненты системы за пределами R), вероятно, относительно малы, поэтому рассмотрим видя, какие обновления доступны (догадываться, что я сделал сегодня) ;-)

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