Хорошая практика в отношении систем управления несколькими пакетами

Некоторые языки программирования поставляются с собственной системой управления пакетами, например, в случае R встроенная install.packagesкоманда устанавливается из репозитория CRAN и обрабатывает зависимости.

Параллельно ОС поставляются с собственными системами управления пакетами, такими как aptкоманда для дистрибутивов Linux на основе Debian.

Я решил , что лучше использовать менеджер пакетов дистрибутива для того, чтобы гарантировать , что все в моей системе будет совместимо (см /programming//a/31293955/1878788 ).

Но вскоре наступил день, когда мне понадобились вещи, которые были недоступны таким образом. Например, программе биоинформатики, которая не была упакована моим дистрибутивом, потребовалась бы какая-то конкретная версия R. Случилось так, что программа была доступна через проект под названием «bioconductor», целью которого было предоставить пакеты R для биоинформатики, гарантируя, что пакеты будут быть совместимыми друг с другом (см. https://www.bioconductor.org/install/#why-biocLite ).

Поэтому я решил не использовать мою систему управления упаковками ОС для R и установить все через biocLiteкоманду, предоставленную проектом bioconductor.

Некоторое время этот подход работал гладко, пока я не обнаружил, что для поддержания согласованных, здоровых и легко восстанавливаемых биоинформатических экосистем некоторые люди решили использовать систему управления пакетами conda. Этот проект, называемый «биоконда», предоставляет не только пакеты R, но и вещи из разных языков с возможностью простого переключения версий и т. Д. (См. Https://bioconda.github.io/ ).

Затем я решил использовать этот подход, и он работал гладко, пока мне не понадобился пакет R, который не был предоставлен bioconda / conda. Якобы это очень просто, но мои попытки создать пакет conda не увенчались успехом, затем я попытался установить пакет, используя способ bioconductor, и он снова не удался. У меня сложилось впечатление, что каким-то образом неправильная установка R использовалась механизмами сборки пакетов. Поэтому я решил стереть свою (еще очень молодую) установку conda и вернуться к моей биокондукторной экосистеме.

Мне интересно, как долго мне придется переходить с одного подхода на другой. Существуют ли общие рекомендации относительно того, как бороться с этими множественными, мешающими и перекрывающимися уровнями управления пакетами?

Редактирование (14/09/2017) : Еще один вариант, который я рассмотрел, - это использовать альтернативные менеджеры пакетов на уровне ОС, такие как Guix или Nix .

Я не уверен, что доступно для R (слышал о REnv), но для Python я выбрал прагматический подход, согласно которому каждый пользователь несет ответственность за свою собственную среду Python pyenv(то же самое верно для Perl с perlbrewи Ruby с RVM). Таким образом, пользователи могут создавать свою собственную оптимальную среду для каждого проекта без моей помощи ( pyenvуправляет установками Python, а затем вы можете использовать их pipдля установки локальных модулей для этой конкретной установки Python).

Системные пакеты используются только для системных нужд.

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

Так что я бы сказал, что лучший способ в этом случае - использовать встроенные функции языка. Если R-создатели создадут официальный инструмент для управления пакетами, это было бы здорово, но использование неофициальных инструментов несколько рискованно.