Гарна практика щодо декількох систем управління пакетами

Деякі мови програмування поставляються із власною системою управління пакетами, наприклад, у випадку R, вбудована install.packagesкоманда встановлюється із сховища CRAN та займається залежностями.

Паралельно ОС надходить із власною системою управління пакетами, як aptкоманда для Linux-дистрибутивів на основі debian.

Я вирішив, що краще використовувати диспетчер пакунків дистрибутива, щоб гарантувати, що все в моїй системі буде сумісним (див. Https://stackoverflow.com/a/31293955/1878788 ).

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

Тому я вирішив не використовувати свою систему управління упаковкою ОС для R, а встановити все за допомогою biocLiteкоманди, передбаченої проектом біокондуктора.

Цей підхід деякий час проходив безперебійно, поки я не виявив, що для підтримки цілісних, здорових та легко відновлюваних екосистем біоінформатики деякі люди вирішили використовувати систему управління пакетами conda. Цей проект, який називається "bioconda", пропонує не лише пакети R, але й речі різного роду мов, з можливістю легко перемикати версії тощо. (Див. Https://bioconda.github.io/ ).

Тоді я вирішив замість цього застосувати цей підхід, і він пройшов гладко, поки мені не знадобився пакет R, який не був забезпечений біокондою / кондою. Нібито це дуже просто, але мої спроби зробити конда-пакет не вдалися, тоді я спробував встановити пакет за допомогою біопровідника, і він знову не вдався. У мене складається враження, що механізми побудови пакетів якось використовували неправильну установку R. Тому я вирішив стерти мою (ще дуже молоду) установку конди і повернутися до моєї екосистеми біопровідників.

Мені цікаво, як довго мені доведеться переходити з одного підходу до іншого. Чи є загальна хороша практика щодо того, як боротися з цими численними рівнями, що перешкоджають і перекриваються, управління пакетами?

Редагувати (14.09.2017) : Ще один варіант, який я вважав, - це використання альтернативних менеджерів пакетів на рівні ОС, таких як Guix або Nix .

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

Системні пакети використовуються лише для системних потреб.

Зазвичай краще використовувати системний менеджер пакетів. Але якщо ви використовуєте сучасні мови, це швидко розвиваються, стабільні дистрибутиви не включатимуть нові пакети та версії. І не дуже популярні пакети ніколи не можуть бути включені до сховищ.

Тому я б сказав, що найкращим способом у такому випадку є використання вбудованих функцій мови. Якщо R-творці створять офіційний інструмент для управління пакунками, було б чудово, але використовувати неофіційні інструменти дещо ризиковано.