Некоторые языки программирования поставляются со своей собственной системой управления пакетами, например, в случае R, встроенная install.packages команда устанавливается из репозитория CRAN и работает с зависимостями.
Параллельно ОС поставляются со своими собственными системами управления пакетами, такими как apt команда для дистрибутивов Linux на основе debian.
Я решил, что лучше использовать диспетчер пакетов дистрибутива, чтобы гарантировать, что все в моей системе будет совместимо (см. https://stackoverflow.com/a/31293955/1878788).
Но вскоре настал день, когда мне потребовались вещи, которых в таком случае не было. Например, программа биоинформатики, которая не была упакована в моем дистрибутиве, потребовала бы определенной версии R. Случилось так, что программа была доступна через проект под названием «bioconductor», целью которого было предоставление пакетов R для биоинформатики, гарантируя, что пакеты будут быть совместимыми друг с другом (см. https://www.bioconductor.org/install/#why-biocLite).
Поэтому я решил не использовать свою систему управления пакетами ОС для R и установить все через biocLite команда предоставлена проектом биокондуктора.
Этот подход работал гладко в течение некоторого времени, пока я не обнаружил, что для поддержания согласованной, здоровой и легко восстанавливаемой биоинформатической экосистемы некоторые люди решили использовать систему управления пакетами conda. Этот проект под названием «bioconda» предоставляет не только пакеты R, но и вещи на всех языках, с возможностью легко переключать версии и т. Д. (См. https://bioconda.github.io/).
Затем я решил использовать этот подход, и он работал гладко, пока мне не понадобился пакет R, который не был предоставлен bioconda / conda. Предположительно это очень просто, но мои попытки создать пакет conda потерпели неудачу, затем я попытался установить пакет, используя способ биокондуктора, и это снова не удалось. У меня сложилось впечатление, что механизмы сборки пакетов каким-то образом использовали неправильную установку R. Поэтому я решил стереть мою (еще очень молодую) установку кондуктора и вернуться к своей экосистеме биокондукторов.
Мне интересно, сколько времени мне придется перепрыгивать с одного подхода на другой. Есть ли общие передовые методы работы с этими множественными, мешающими и перекрывающимися уровнями управления пакетами?
Изменить (14.09.2017): Еще один вариант, который я рассмотрел, - использовать альтернативные менеджеры пакетов на уровне ОС, например Guix или Nix.
Я не уверен, что доступно для R (слышал о REnv), но для Python я решил использовать прагматичный подход, согласно которому каждый пользователь несет ответственность за свою собственную среду Python с pyenv (то же самое верно для Perl с perlbrew и Руби с RVM). Таким образом, пользователи могут создавать свою собственную оптимальную среду для каждого проекта без моей помощи (pyenv управляет установками Python, а затем вы можете использовать pip для установки модулей, локальных для этой конкретной установки Python).
Системные пакеты используются только для системных нужд.
Обычно лучше использовать системный менеджер пакетов. Но если вы используете современные языки, они быстро развиваются, стабильные дистрибутивы не будут включать новые пакеты и версии. А не очень популярные пакеты никогда нельзя включать в репозитории.
Поэтому я бы сказал, что лучший способ в этом случае - использовать встроенные функции языка. Если создатели R создадут официальный инструмент для управления пакетами, это будет замечательно, но использование неофициальных инструментов несколько рискованно.