Блог

Главная - Вопросы по программированию - Управление зависимостями в R

Управление зависимостями в R

#r #dependencies #package

#r #зависимости #пакет

Вопрос:

Есть ли в R инструмент управления зависимостями для облегчения зависимостей, зависящих от конкретного проекта? Я ищу что-то похожее на Java maven, Ruby bundler, Python virtualenv, npm Node и т. Д.

Я знаю о предложении «Depends» в файле ОПИСАНИЯ, а также о средстве R_LIBS, но, похоже, они не работают согласованно, чтобы обеспечить решение для некоторых очень распространенных рабочих процессов.

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

 my_project/.Rlibs/*

Комментарии:

1. ознакомьтесь с пакетами R ProjectTemplate и devtools .

2. ProjectTemplate не поддерживает это. В документах говорится, что библиотеки уже должны быть установлены: «библиотеки: это разделенный запятыми список всех пакетов R, которые пользователь хочет автоматически загружать при вызове load.project() . Эти пакеты должны быть уже установлены перед вызовом load.project() . По умолчанию в этот список включены пакеты reshape, plyr, ggplot2, stringr и lubridate.»

3. похоже, что в devtools есть отличные вещи, но они также не дотягивают до этого.

4. Я думаю, что то, что вы хотите, в высшей степени выполнимо в R, но никто еще этого не сделал.

5. Если вам нужно решение devtools, dev_mode(); install_deps("path/to/package"); check() это довольно близко.

Ответ №1:

К сожалению, Depends: внутри DESCRIPTION: файла все, что вы получаете по следующим причинам:

  • R сам по себе достаточно кроссплатформенный, но это означает, что нам нужно, чтобы это работало на разных платформах и операционных системах
  • Кодирование зависит: для пакетов beyond R требуется кодирование зависимостей переносимым способом в разных операционных системах — удачи в кодировании даже чего-то простого, такого как «графическая библиотека PNG», таким образом, который может быть однозначно разрешен в разных системах
  • В Windows нет диспетчера пакетов
  • AFAIK OS X не имеет менеджера пакетов, который объединяет то, что поставляет Apple, и то, что предоставляют другие проекты с открытым исходным кодом
  • Даже среди дистрибутивов Linux вы не получаете согласованности: просто возьмите RStudio в качестве примера, который поставляется в двух пакетах (которые все предоставляют свои зависимости!) для RedHat / Fedora и Debian / Ubuntu

Это сложная проблема.

Ответ №2:

packrat Пакет точно предназначен для достижения следующего:

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

Это позволяет устанавливать разные версии одних и тех же пакетов в разные библиотеки локальных пакетов проекта.

Я добавляю этот ответ, хотя этому вопросу 5 лет, потому что это решение, по-видимому, еще не существовало на момент, когда был задан вопрос (насколько я могу судить, packrat впервые появилось на CRAN в 2014 году).).

Обновление (ноябрь 2019)

Заменен новый пакет R. renv packrat

Комментарии:

1. Спасибо Гийому. Пожалуйста, посмотрите мой ответ на аналогичный комментарий в принятом ответе. Вполне возможно, что все изменилось, поэтому не стесняйтесь комментировать соответствующим образом.

2. Спасибо, я пропустил этот комментарий выше перед публикацией. Но я полагаю, что важно предоставить видимость packrat с ответом (комментарии легко пропустить).

3. Согласен. Спасибо, Гийом. 🙂

Ответ №3:

В качестве промежуточного шага я написал новый пакет rbundler. Он устанавливает зависимости проекта в подкаталог, специфичный для проекта (например <PROJECT>/.Rbundle ), что позволяет пользователю избежать использования глобальных библиотек.

Мы используем rbundler at Opower уже несколько месяцев и увидели значительное улучшение рабочего процесса разработчика, тестируемости и ремонтопригодности внутренних пакетов. В сочетании с нашим внутренним репозиторием пакетов мы смогли стабилизировать разработку примерно дюжины пакетов для использования в производственных приложениях.

Общий рабочий процесс:

  • Ознакомьтесь с проектом на github
  • компакт-диск в каталог проекта
  • Запустите R

  • Из консоли R:

    библиотека (rbundler)

    bundle(‘.’)

Все зависимости будут установлены в ./.Rbundle , и .Renviron будет создан файл со следующим содержимым:

 R_LIBS_USER='.Rbundle'

Любые операции R, выполняемые из этого каталога проекта, будут привязаны к зависимостям библиотеки и пакета, специфичным для проекта. Обратите внимание, что, хотя этот метод использует ОПИСАНИЕ пакета для определения зависимостей, ему не обязательно иметь фактическую структуру пакета. Таким образом, rbundler становится общим инструментом для управления проектом R, будь то простой скрипт или полноценный пакет.

Комментарии:

1. На первый взгляд мне кажется, что это именно то, что PackRat ( rstudio.github.io/packrat ) делает, который недавно был опубликован командой RStudio. Я ошибаюсь?

2. Спасибо, что поднял этот вопрос, @jhin. Я говорил об этом с @hadley и ребятами из RStudio примерно в то время, когда я начал разрабатывать rbundler . Разница в том, что rbundler он ориентирован на разработку пакетов и использует явные зависимости в вашем DESCRIPTION файле, тогда PackRat как фокусируется на общей разработке проекта и выводит ваши зависимости через отражение. PackRat имеет некоторые дополнительные функции для моментального снимка ваших зависимостей, чтобы облегчить развертывание и совместное использование. Я считаю, что это было их главным приоритетом в качестве решения для управления размещенными проектами.

3. А, понятно. Я просто пытался понять рабочий процесс развертывания пакета с помощью rbundler, но я не совсем уверен, что правильно понял. Давайте предположим, что я разработал пакет, и я связываю его зависимости с помощью rbundler. Что происходит, когда кто-то устанавливает мой пакет, например, используя devtools ‘install («mypack»)’ из мини-хранилища (предполагая, что это то, что вы подразумеваете под «нашим внутренним репозиторием пакетов»)? Как разрешаются зависимости пакетов?

4. Побочный вопрос: как пакеты хранятся с помощью rbundler? Я понимаю, что PackRat в основном хранит пакеты в исходном виде, чтобы сделать зависимости переносимыми на разные платформы. Как это решается с помощью rbundler? (Может быть, вы хотите включить эту информацию на страницы проекта на GitHub / CRAN? По крайней мере, я не смог найти там никаких ответов на эти вопросы.)

5. rbundler не делает ничего необычного для пакетов, он просто управляет специфичным для проекта library и устанавливает туда пакеты. Как упоминалось в ответе здесь, библиотека настраивается путем переопределения стандарта R. R_LIBS_USER Возможно, мне следует ссылаться на конфигурацию управления библиотекой R из README.

Ответ №4:

Вы могли бы использовать следующий рабочий процесс:

1) создайте файл сценария, который содержит все, что вы хотите настроить, и сохраните его в своем каталоге projectd, например, как projectInit.R

2) создайте этот скрипт из вашего .Rprofile (или любого другого файла, выполняемого R при запуске) с помощью инструкции try 

 try(source("./projectInit.R"), silent=TRUE)

Это гарантирует, что даже при отсутствии projectInit.R найден, R запускается без сообщения об ошибке

3) если вы запустите R в каталоге вашего проекта, будет получен файл projectInit.R, если он присутствует в каталоге, и вы готовы к работе

Это с точки зрения Linux, но должно работать одинаково и под Windows, и под Mac.

Комментарии:

1. Извините, я не видел часть «установить». Здесь я должен согласиться с Дирком — это должно быть специфично для конкретной платформы, но есть, например, удобный скрипт bash, который может достичь всего, чего вы хотите (совместно с источником вышеупомянутого файла projectInit.R .