ภาษาการเขียนโปรแกรมบางภาษามาพร้อมกับระบบการจัดการแพคเกจของตนเองเช่นในกรณีของ R install.packagesคำสั่งในตัวจะติดตั้งจากที่เก็บ CRAN และจัดการกับการพึ่งพา
ในทางตรงกันข้ามระบบปฏิบัติการมาพร้อมกับระบบการจัดการแพกเกจของตัวเองเช่นaptคำสั่งสำหรับการแจกแจงลินุกซ์ที่ใช้เดเบียน
ฉันตัดสินใจว่าควรใช้ตัวจัดการแพคเกจการกระจายเพื่อเป็นการรับประกันว่าทุกอย่างในระบบของฉันจะใช้งานร่วมกันได้ (ดู/programming//a/31293955/1878788 )
แต่ไม่นานมานี้วันหนึ่งเมื่อฉันต้องการสิ่งที่ไม่มีในแบบนี้ ตัวอย่างเช่นโปรแกรมชีวสารสนเทศศาสตร์ที่ไม่ได้บรรจุโดยการแจกจ่ายของฉันจะต้องมีรุ่นที่เฉพาะเจาะจงของอาร์มันเกิดขึ้นว่าโปรแกรมนั้นสามารถใช้ได้ผ่านโครงการที่ชื่อว่า "bioconductor" ซึ่งมีเป้าหมายคือการให้แพคเกจ R สำหรับชีวสารสนเทศศาสตร์ ใช้งานร่วมกันได้ (ดูhttps://www.bioconductor.org/install/#why-biocLite )
ดังนั้นฉันตัดสินใจที่จะไม่ใช้ระบบการจัดการบรรจุภัณฑ์ OS ของฉันสำหรับ R และติดตั้งทุกอย่างผ่านbiocLiteคำสั่งที่ได้รับจากโครงการ bioconductor
วิธีการนี้ดำเนินไปอย่างราบรื่นจนกระทั่งบางครั้งฉันค้นพบว่าเพื่อรักษาระบบนิเวศทางชีวสารสนเทศที่เชื่อมโยงกันมีสุขภาพดีและสร้างใหม่ได้อย่างง่ายดายบางคนตัดสินใจใช้ระบบการจัดการแพคเกจ conda โครงการนี้เรียกว่า "bioconda" ไม่เพียง แต่ให้แพ็คเกจ R เท่านั้น แต่ยังมีสิ่งต่าง ๆ จากภาษาทุกประเภทที่มีความเป็นไปได้ที่จะเปลี่ยนเวอร์ชั่นได้อย่างง่ายดายและอื่น ๆ (ดูhttps://bioconda.github.io/ )
ฉันจึงตัดสินใจใช้วิธีนี้แทนและมันก็ดำเนินไปอย่างราบรื่นจนกระทั่งฉันต้องการแพ็คเกจ R ที่ไม่ได้จัดทำโดย bioconda / conda มันง่ายมากที่คาดคะเน แต่ความพยายามของฉันในการทำชุด conda ล้มเหลวจากนั้นฉันพยายามติดตั้งแพคเกจโดยใช้วิธีการทางชีวภาพและมันล้มเหลวอีกครั้ง ฉันรู้สึกว่าการติดตั้ง R อย่างไม่ถูกต้องกำลังถูกใช้โดยกลไกการสร้างบรรจุภัณฑ์ ดังนั้นฉันตัดสินใจลบการติดตั้ง conda ของฉัน (ยังเด็กมาก) และกลับไปที่ระบบนิเวศตัวสะสมทางชีวภาพของฉัน
ฉันสงสัยว่าฉันจะต้องกระโดดจากวิธีหนึ่งไปอีกนานแค่ไหน มีวิธีปฏิบัติที่ดีโดยทั่วไปเกี่ยวกับวิธีจัดการกับการจัดการบรรจุภัณฑ์หลายระดับรบกวนหรือซ้อนทับกันหรือไม่?
แก้ไข (14/09/2017) : แต่เราพิจารณาตัวเลือกอื่นคือการใช้แพคเกจผู้จัดการ OS ระดับทางเลือกเช่นGuixหรือห้าม