일부 프로그래밍 언어는 자체 패키지 관리 시스템과 함께 제공됩니다. 예를 들어 R의 경우 내장 install.packages명령이 CRAN 저장소에서 설치되어 종속성을 처리합니다.
이와 동시에 OS에는 apt데비안 기반 Linux 배포판 명령 과 같은 자체 패키지 관리 시스템이 제공됩니다.
시스템의 모든 것이 호환되도록하기 위해 배포판의 패키지 관리자를 사용하는 것이 더 좋다고 결정했습니다 ( /programming//a/31293955/1878788 참조 ).
그러나이 방법으로는 사용할 수없는 것들이 필요한 날이 곧 찾아 왔습니다. 예를 들어, 배포판에 포함되지 않은 생물 정보학 프로그램에는 특정 버전의 R이 필요합니다.이 프로그램은 생물 정보학을위한 R 패키지를 제공하여 패키지가 서로 호환 가능합니다 ( https://www.bioconductor.org/install/#why-biocLite 참조 ).
그래서 R에 OS 패키징 관리 시스템을 사용하지 않기로 결정 biocLite했으며, 생물 전도체 프로젝트에서 제공 하는 명령을 통해 모든 것을 설치 했습니다.
이 접근 방식은 일관성 있고 건강하며 쉽게 재구성 가능한 생물 정보학 생태계를 유지하기 위해 일부 사람들이 콘다 패키지 관리 시스템을 사용하기로 결정한 때까지 한동안 순조롭게 진행되었습니다. "bioconda"라고하는이 프로젝트는 R 패키지뿐만 아니라 모든 종류의 언어로 된 버전을 쉽게 전환 할 수있는 기능을 제공합니다 ( https://bioconda.github.io/ 참조 ).
그런 다음이 접근법을 대신 사용하기로 결정했으며 bioconda / conda가 제공하지 않은 R 패키지가 필요할 때까지 원활하게 실행되었습니다. 매우 쉬운 일이지만 conda 패키지를 만들려는 시도가 실패한 다음 bioconductor 방식으로 패키지를 설치하려고 시도했지만 다시 실패했습니다. 어떻게 든 잘못된 R 설치가 패키지 작성 메커니즘에 의해 사용되었다는 인상을 받았습니다. 그래서 (아직도 아주 어린) 콘다 설치를 지우고 바이오 컨덕터 생태계로 돌아 가기로 결정했습니다.
한 접근 방식에서 다른 접근 방식으로 얼마나 오래 뛰어야하는지 궁금합니다. 이러한 다중, 간섭 및 겹치는 수준의 패키지 관리를 처리하는 방법에 대한 일반적인 모범 사례가 있습니까?
편집 (14/09/2017) : 내가 고려한 또 다른 옵션은 Guix 또는 Nix 와 같은 대체 OS 레벨 패키지 관리자를 사용하는 것 입니다.