Dobra praktyka dotycząca systemów zarządzania wieloma pakietami

Niektóre języki programowania mają własny system zarządzania pakietami, na przykład w przypadku R wbudowane install.packagespolecenie instaluje się z repozytorium CRAN i zajmuje się zależnościami.

Równolegle systemy operacyjne mają własne systemy zarządzania pakietami, takie jak aptkomenda dla dystrybucji Linuksa opartych na Debianie.

Zdecydowałem, że lepiej jest użyć menedżera pakietów dystrybucji, aby zagwarantować, że wszystko w moim systemie będzie kompatybilne (patrz /programming//a/31293955/1878788 ).

Ale wkrótce nadszedł dzień, kiedy potrzebowałem rzeczy, które nie były dostępne w ten sposób. Na przykład program bioinformatyczny, który nie został spakowany przez moją dystrybucję, wymagałby określonej wersji R. Zdarzyło się, że program był dostępny w ramach projektu o nazwie „bioconductor”, którego celem było zapewnienie pakietów R dla bioinformatyki, zapewniając, że pakiety będą być ze sobą kompatybilni (patrz https://www.bioconductor.org/install/#why-biocLite ).

Postanowiłem więc nie używać mojego systemu zarządzania biocLitepakietami OS dla R i instalowałem wszystko za pomocą polecenia dostarczonego przez projekt bioprzewodnika.

To podejście działało płynnie przez pewien czas, dopóki nie odkryłem, że w celu utrzymania spójnych, zdrowych i łatwych do odbudowania ekosystemów bioinformatycznych, niektórzy ludzie zdecydowali się na użycie systemu zarządzania pakietami conda. Ten projekt, zwany „bioconda”, zapewnia nie tylko pakiety R, ale także różne rodzaje języków, z możliwością łatwej zmiany wersji itd. (Patrz https://bioconda.github.io/ ).

Następnie postanowiłem zastosować to podejście i działało ono płynnie, dopóki nie potrzebowałem pakietu R, który nie został dostarczony przez bioconda / conda. Jest to podobno super łatwe, ale moje próby stworzenia pakietu Conda zakończyły się niepowodzeniem, a następnie spróbowałem zainstalować pakiet przy użyciu bioprzewodnika i znów się nie powiodło. Mam wrażenie, że mechanizmy budowania pakietów wykorzystały jakąś niewłaściwą instalację R. Postanowiłem więc usunąć moją (wciąż bardzo młodą) instalację conda i wrócić do ekosystemu bioprzewodnika.

Zastanawiam się, jak długo będę musiał skakać z jednego podejścia na drugie. Czy istnieją ogólne dobre praktyki dotyczące radzenia sobie z tymi wieloma zakłócającymi i nakładającymi się poziomami zarządzania pakietami?

Edycja (14/09/2017) : Kolejną rozważaną przeze mnie opcją jest użycie alternatywnych menedżerów pakietów na poziomie systemu operacyjnego, takich jak Guix lub Nix .

Nie jestem pewien, co jest dostępne dla R (słyszałem o REnv), ale dla Pythona zdecydowałem się na pragmatyczne podejście, z którym każdy użytkownik jest odpowiedzialny za swoje własne środowisko Pythona pyenv(to samo dotyczy Perla z perlbrewi Ruby z RVM). W ten sposób użytkownicy mogą tworzyć własne optymalne środowisko dla każdego projektu bez mojej pomocy ( pyenvzarządza instalacjami w języku Python, a następnie można użyć pipdo zainstalowania modułów lokalnych dla tej konkretnej instalacji w języku Python).

Pakiety systemowe są używane tylko na potrzeby systemowe.

Zwykle lepiej jest użyć menedżera pakietów systemowych. Ale jeśli używasz nowoczesnych języków, te ewoluujące szybkie, stabilne dystrybucje nie będą zawierać nowych pakietów i wersji. I mało popularne pakiety nigdy nie mogą być zawarte w repozytoriach.

Powiedziałbym więc, że najlepszym sposobem jest użycie wbudowanych funkcji języka. Jeśli R-twórcy stworzą oficjalne narzędzie do zarządzania pakietami, byłoby świetnie, ale używanie nieoficjalnych narzędzi jest nieco ryzykowne.