Thực hành tốt về nhiều hệ thống quản lý gói

Một số ngôn ngữ lập trình đi kèm với hệ thống quản lý gói riêng của họ, ví dụ, trong trường hợp R, install.packageslệnh tích hợp sẽ cài đặt từ kho CRAN và xử lý các phụ thuộc.

Song song, HĐH đi kèm với các hệ thống quản lý gói riêng của họ, giống như aptlệnh cho các bản phân phối Linux dựa trên debian.

Tôi đã quyết định rằng tốt hơn là sử dụng trình quản lý gói của phân phối, để đảm bảo rằng mọi thứ trên hệ thống của tôi sẽ tương thích (xem /programming//a/31293955/1878788 ).

Nhưng sớm đến một ngày khi tôi cần những thứ không có sẵn theo cách này. Ví dụ, một chương trình tin sinh học không được phân phối bởi nhà phân phối của tôi sẽ yêu cầu một số phiên bản cụ thể của R. Nó đã xảy ra rằng chương trình có sẵn thông qua một dự án có tên là "chất sinh học", với mục tiêu là cung cấp các gói R cho tin sinh học, đảm bảo rằng các gói sẽ tương thích với nhau (xem https://www.bioconductor.org/install/#why-biocLite ).

Vì vậy, tôi quyết định không sử dụng hệ thống quản lý bao bì hệ điều hành của mình cho R và cài đặt mọi thứ thông qua biocLitelệnh được cung cấp bởi dự án bộ lọc sinh học.

Cách tiếp cận này diễn ra suôn sẻ trong một thời gian, cho đến khi tôi phát hiện ra rằng để duy trì hệ sinh thái tin sinh học mạch lạc, lành mạnh và dễ xây dựng lại, một số người đã quyết định sử dụng hệ thống quản lý gói conda. Dự án này, được gọi là "bioconda" không chỉ cung cấp các gói R, mà còn từ mọi loại ngôn ngữ, với khả năng dễ dàng chuyển đổi các phiên bản, v.v. (xem https://bioconda.github.io/ ).

Sau đó, tôi đã quyết định sử dụng phương pháp này thay thế và nó chạy trơn tru cho đến khi tôi cần một gói R không được cung cấp bởi bioconda / conda. Nó được cho là siêu dễ dàng, nhưng những nỗ lực của tôi trong việc tạo ra một gói conda đã thất bại, sau đó tôi đã cố gắng cài đặt gói bằng cách sử dụng phương pháp sinh học, và nó lại thất bại. Tôi có cảm tưởng rằng bằng cách nào đó, cài đặt R sai đã được sử dụng bởi các cơ chế xây dựng gói. Vì vậy, tôi quyết định xóa cài đặt conda (vẫn còn rất trẻ) và quay trở lại hệ sinh thái dẫn điện sinh học của tôi.

Tôi tự hỏi bao lâu tôi sẽ phải nhảy từ cách này sang cách khác. Có thực tiễn tốt chung chung về cách đối phó với các cấp độ quản lý gói, giao thoa và chồng chéo này không?

Chỉnh sửa (14/09/2017) : Tuy nhiên, một tùy chọn khác tôi đã xem xét là sử dụng các trình quản lý gói cấp hệ điều hành thay thế, như Guix hoặc Nix .

Tôi không chắc những gì có sẵn cho R (nghe về REnv), nhưng đối với Python tôi đã quyết định cách tiếp cận thực tế rằng mọi người dùng chịu trách nhiệm cho môi trường Python của riêng họ pyenv(tương tự với Perl với perlbrewvà Ruby với RVM). Bằng cách đó, người dùng có thể tạo môi trường tối ưu của riêng họ cho mọi dự án mà không cần sự trợ giúp của tôi ( pyenvquản lý cài đặt Python và sau đó bạn có thể sử dụng pipđể cài đặt các mô đun cục bộ cho cài đặt Python cụ thể đó).

Gói hệ thống chỉ được sử dụng cho nhu cầu hệ thống.

Thông thường tốt hơn là sử dụng trình quản lý gói hệ thống. Nhưng nếu bạn đang sử dụng các ngôn ngữ hiện đại, các phân phối phát triển nhanh, ổn định sẽ không bao gồm các gói và phiên bản mới. Và các gói không phổ biến không bao giờ có thể được bao gồm trong kho.

Vì vậy, tôi muốn nói, cách tốt nhất trong trường hợp đó là sử dụng các hàm dựng sẵn của ngôn ngữ. Nếu người tạo R sẽ tạo ra công cụ chính thức để quản lý các gói, điều đó thật tuyệt, nhưng sử dụng các công cụ không chính thức có phần rủi ro.