2012-01-14 2 views
19

Я разрабатываю среду для воспроизводимых вычислений с R. Одна проблема, с которой я борюсь, заключается в том, что некоторый R-код может отлично работать в версии XY-Z пакета, но затем почему вы пытаетесь воспроизвести его через 3 года, пакеты обновились, некоторые функции изменены, и код больше не запускается. Эта проблема затрагивает также, например, Sweave документы, которые используют пакеты.Как установить и управлять многими версиями пакетов R

Единственный способ уверенно воспроизвести результаты - это установить версию R и версию пакетов, которые были использованы оригинальным автором. Если бы это был единственный случай, можно было извлечь материал из архивов CRAN и установить соответствующие версии. Но для моих фреймворков это непрактично, и мне нужно предустановить версии пакетов.

Предположим теперь, что я ограничиваю себя одной версией R, например. 2,14. Каким будет практический способ установки многих версий R-пакетов, чтобы я мог загружать их на лету? Я полагаю, что могу сделать что-то вроде создания отдельных каталогов библиотек для каждой версии каждого пакета, а затем использовать пользовательские аргументы lib.loc при их загрузке. Однако это будет грязно. Любые советы или предыдущие попытки сделать что-то подобное?

Мои рамки работают на сервере Ubuntu.

+0

Вы знакомы с dev_mode в пакете devtools? IIRC решает аналогичную проблему. – baptiste

+0

Не совсем. Это просто изменяет ваш libpath на временный файл sandbox. Но он не обеспечивает никакой системы за ее пределами. – Jeroen

+0

Это дубликат. Смотрите мой ответ здесь: http://stackoverflow.com/questions/8343686/how-to-install-2-different-r-versions-on-debian/8343739#8343739 – Oz123

ответ

4

Вы можете установить пакеты с версиями (например, переименовать в каталог foo_1.0 вместо foo) и запрограммировать версии, которые вы хотите воссоздать, в один библиотечный файл. Очевидно, что пакеты действительно могут жить в отдельном дереве, поэтому у вас может быть library.projectX/foo ->library.all/foo/1.0.

+0

Кроме того, вы могли бы изменить переменную среды R_LIBS на соответствующий каталог для этого проекта. –

-1

Я бы попытался изменить файл DESCRIPTION и изменить поле «Пакет» там, добавив номер версии.

Например, вы загружаете источник пакета a с страницы CRAN (http://cran.r-project.org/web/packages/pls/). Распакуйте сжатый файл (pls_2.3-0.zip) в каталог («pls /»). Следующие шаги состоят в изменении имени пакета в DESCRIPTION («PLS/DESCRIPTION») и установке с помощью команды R «R CMD INSTALL pls /», где «pls /» - это путь к источнику пакета с измененным файлом DESCRIPTION.

Игра с библиотечными дорожками R кажется мне опасной.

+5

Игра с именами пакетов еще более опасна, потому что вы нарушаете все зависимости. Пути библиотек предназначены для воспроизведения в отличие от имен пакетов. –

1

Операционная система дает вам еще больше ручек для полного разделения, а стек Debian/Ubuntu - тонну доступных. Два, с которыми я играл, -

  • chroot environment: Мы используем это, чтобы завершить отдельные среды сборки от хост-машин. Например, все загружаемые мной файлы Debian встроены в chroot i386 pbuilder, размещенный на моем сервере amd64 Ubuntu. Chroot - очень мощный системный вызов Unix. Хроты, и особенно построенная сверху система pbuilder (для создания пакета Debian) предназначены для работы без головы.

  • Виртуальные машины: Это дает вам полную общность. Мое не очень мощное поле легко обрабатывает три виртуальные машины: Debian i386, Ubuntu i386, а также Windoze XP. Для этого я в настоящее время использую KVM вместе с libvirt; это конкретный Linux. В прошлом я также использовал VirtualBox и VMware.