เหตุใดจึงต้องใช้ตัวจัดการแพคเกจเหนือโฟลเดอร์ไลบรารี

เมื่อฉันคิดถึงข้อดีข้อเสียของโฟลเดอร์ไลบรารี่แบบคงที่และตัวจัดการแพ็กเกจฉันรู้สึกว่าโฟลเดอร์ไลบรารี่เป็นวิธีที่ดีกว่า

ข้อดีที่ฉันเห็นด้วยโฟลเดอร์ไลบรารี:

1. ไม่จำเป็นต้องมีเครื่องมือภายนอกในการจัดการแพ็คเกจ
2. ไม่จำเป็นต้องสร้างการเชื่อมต่ออินเทอร์เน็ต
3. สร้างได้เร็วขึ้น (ไม่มีการตรวจสอบแพ็คเกจ)
4. สภาพแวดล้อมที่เรียบง่าย (ต้องการความรู้น้อยกว่า)

ข้อดีที่ฉันเห็นกับผู้จัดการบรรจุภัณฑ์:

1. ช่วยต้นไม้ที่พึ่งพาได้ซับซ้อน (และสามารถจัดการดาวน์โหลดการอ้างอิงพร้อมกับการพึ่งพาทั้งหมด)
2. ช่วยตรวจสอบว่ามีเวอร์ชั่นใหม่หรือไม่

ดูเหมือนว่าอุตสาหกรรมได้ตัดสินใจที่จะทำตามเส้นทางผู้จัดการบรรจุภัณฑ์สำหรับเกือบทุกอย่างที่สร้างขึ้นในวันนี้ แล้วฉันจะพลาดอะไร

จุดสำคัญที่หายไปจากคำตอบอื่น ๆ :

การใช้ตัวจัดการแพคเกจหมายถึงการมีการกำหนดค่าที่ระบุว่าคุณกำลังใช้เวอร์ชันไลบรารี่ใดและตรวจสอบให้แน่ใจว่าข้อมูลการกำหนดค่านั้นถูกต้องจริง

การรู้จักไลบรารีที่คุณใช้และเวอร์ชันใดเป็นสิ่งสำคัญหากคุณ:

• จำเป็นต้องอัปเดตห้องสมุดเนื่องจากช่องโหว่ที่สำคัญ / การรักษาความปลอดภัย
• หรือเพียงแค่ต้องตรวจสอบว่าช่องโหว่ด้านความปลอดภัยที่ประกาศนั้นส่งผลต่อคุณ

นอกจากนี้เมื่อคุณทำการอัปเดตจริง ๆ ตัวจัดการแพคเกจ (ปกติ) ทำให้แน่ใจว่าการอ้างอิงสกรรมกริยาใด ๆ ได้รับการปรับปรุงตามที่จำเป็น

ในขณะที่มีlibโฟลเดอร์คุณมีไฟล์ (อาจเป็นเลขฐานสองและอาจแก้ไขได้) และคุณต้องเดาว่ามันมาจากไหนและเป็นเวอร์ชั่นใด (หรือเชื่อใจว่า README บางอันซึ่งอาจจะใช่หรือไม่ถูกต้อง )

ในการพูดถึงประเด็นอื่น ๆ ของคุณ:

ไม่ต้องใช้เครื่องมือภายนอกในการจัดการแพ็คเกจ

จริง แต่ก) ในฐานะนักพัฒนาซอฟต์แวร์ที่คุณต้องติดตั้งเครื่องมือมากมายดังนั้นอีกหนึ่งไม่สำคัญและ b) โดยทั่วไปจะมีเพียงหนึ่งหรือไม่กี่ตัวจัดการแพคเกจในสาขาที่กำหนด (Maven / Gradle สำหรับ Java npm สำหรับ JS / TypeScript ฯลฯ ) ดังนั้นจึงไม่เหมือนที่คุณต้องการติดตั้งหลายสิบรายการ

ไม่จำเป็นต้องสร้างการเชื่อมต่ออินเทอร์เน็ต

ผู้จัดการแพ็คเกจทั้งหมดที่ฉันรู้จักทำงานแบบออฟไลน์เมื่อพวกเขาดาวน์โหลดการอ้างอิงที่ต้องการ (ซึ่งสามารถเกิดขึ้นได้ทันทีหลังจากดาวน์โหลดโครงการเอง)

สร้างได้เร็วขึ้น (ไม่มีการตรวจสอบแพ็คเกจ)

อาจเป็นจริง แต่ดูเหมือนว่าไม่น่าเป็นไปได้ที่การตรวจสอบแพ็กเกจออฟไลน์จะใช้เวลานานพอสมควร (เป็นเพียงการเปรียบเทียบตัวเลขบางเวอร์ชัน) การตรวจสอบแบบออนไลน์อาจใช้เวลาสักครู่ แต่สามารถปิดได้หากต้องการ (หากเป็นค่าเริ่มต้นแม้ - Maven จะไม่ตรวจสอบการอัปเดตสำหรับรุ่นที่วางจำหน่าย)

สภาพแวดล้อมที่เรียบง่าย (ต้องการความรู้น้อยกว่า)

จริง แต่ตามที่อธิบายไว้ข้างต้นlibโฟลเดอร์ต้องใช้ความรู้ด้วย นอกจากนี้ตามที่อธิบายไว้ข้างต้นคุณอาจทำงานกับผู้จัดการแพคเกจที่แตกต่างกันเพียงเล็กน้อยเท่านั้นซึ่งคุณจะรู้แล้ว

ข้อดีของโฟลเดอร์ lib หายไปอย่างรวดเร็วหลังจากคุณย้ายจากการพัฒนาขนาดเล็กไปสู่งานที่ใหญ่กว่า

ตัวอย่างเช่น "ผลประโยชน์" ที่ไม่ต้องใช้เครื่องมือภายนอกนั้นมีผลงานที่ต้องจัดการการอ้างอิงของคุณด้วยตนเองดังนั้นเครื่องมือจะเป็นตัวคุณ (ในแง่มุมหนึ่งของโลก)

คุณไม่จำเป็นต้องเชื่อมต่ออินเทอร์เน็ตสำหรับผู้จัดการแพ็คเกจ คุณสามารถใช้ที่เก็บข้อมูลในเครื่อง

การสร้างที่เร็วกว่าอาจเป็นจริง แต่ก็ไม่ค่อยมีสิ่งที่ควรพิจารณาว่าจะใช้ตัวจัดการแพคเกจหรือไม่ เราไม่ได้พูดถึงขนาดของความแตกต่างหลังจากทั้งหมดและมันก็ขึ้นอยู่กับการกำหนดค่าของคุณ คุณสามารถสร้างงานช้าได้อย่างง่ายดายโดยใช้ตัวจัดการแพคเกจ แต่นั่นเป็นการก่อวินาศกรรม

สภาพแวดล้อมที่เรียบง่าย (ต้องการความรู้น้อยกว่า)? อีกครั้งในการพัฒนาขนาดเล็กเป็นไปได้แน่นอน คุณอาจจะสามารถถือโครงการไว้ในหัวของคุณอย่างสมบูรณ์ลงไปที่ห้องสมุดไม่กี่แห่งที่ถูกใช้งาน เพิ่ม makefile / สคริปต์สร้างอย่างง่าย ๆ แล้วคุณก็มีแพ็คเกจที่สมบูรณ์

แต่มันไม่ได้ทำให้สภาพแวดล้อมง่ายขึ้นมันทำงานได้ในสภาพแวดล้อมที่เรียบง่ายเท่านั้น ในการพัฒนาขนาดที่ใหญ่ขึ้นคุณจะดีใจที่คุณใช้เครื่องมือมาตรฐานแทนที่จะเป็นโซลูชันที่กำหนดเอง ท้ายที่สุดคุณต้องเรียนรู้เพียงครั้งเดียว (และเมื่อผู้จัดการแพคเกจ du jour ถูกแทนที่ด้วยสิ่งดีๆใหม่คุณต้องเรียนรู้สิ่งนั้นด้วย)

คุณพลาดข้อดีหลายประการของผู้จัดการแพ็คเกจ

1. ผู้จัดการแพ็คเกจช่วยให้คุณหลีกเลี่ยงการตรวจสอบไบนารีขนาดใหญ่ (หลายเมกะไบต์หรือใหญ่กว่า) ในการควบคุมแหล่งที่มา การทำเช่นนี้เป็นการสาปแช่งเครื่องมือการควบคุมแหล่งที่มาจำนวนมากคอมไพล์ที่แพร่หลายเป็นหนึ่งในนั้น เรามีที่เก็บข้อมูลที่ จำกัด ขนาดของ Bit Bucket เมื่อสองสามเดือนก่อนเนื่องจากผู้พัฒนากำลังตรวจสอบใน CocoaPods อีกโครงการหนึ่งอยู่ครึ่งทางแล้วเมื่อเราย้ายจาก SVN เพราะเราได้ตรวจสอบไบนารีทั้งหมดของเรา (และไม่ได้ใช้ NuGet) เนื่องจากผู้จัดการแพ็คเกจจะดาวน์โหลดแพ็คเกจทันทีสำหรับนักพัฒนาแต่ละคนพวกเขาจึงไม่จำเป็นต้องตรวจสอบไบนารีเหล่านี้
2. พวกเขาป้องกันการผสมไฟล์ / ไลบรารีที่เข้ากันไม่ได้ โฟลเดอร์สามารถมีไฟล์ต่าง ๆ ในไลบรารีหากใครบางคนไม่ได้ล้างมันอย่างถูกต้องระหว่างการอัพเกรด ฉันเคยเห็นกรณีที่ไบนารีสองเท่าในโฟลเดอร์ได้รับการอัปเกรดทำให้เกิดข้อผิดพลาดที่แปลกมาก (มันไม่ได้ผิดพลาด!) เราใช้เวลาหลายเดือน (ไม่ใช่ชั่วโมงคนเพียงแค่เวลาโดยรวม) เพื่อคิดหาปัญหา โดยการให้ผู้จัดการแพ็คเกจควบคุมทั้งโฟลเดอร์คุณจะไม่สามารถรับเวอร์ชั่นผสมได้ คุณมั่นใจในความมั่นคง พวกเขายังทำให้ยากต่อการใช้การพึ่งพาที่เข้ากันไม่ได้โดยการอัปเดตทุกอย่างด้วยกันโดยอัตโนมัติติดตั้งเวอร์ชันที่แตกต่างกันตามที่ต้องการหรือแม้กระทั่งการทิ้งคำเตือนหรือข้อผิดพลาดเมื่อพยายามใช้ไลบรารี่รุ่นที่
3. พวกเขาสร้างการประชุมที่ใช้ร่วมกันสำหรับการจัดการห้องสมุด เมื่อนักพัฒนาใหม่เข้าสู่โครงการทีม บริษัท ฯลฯ พวกเขามีแนวโน้มที่จะรู้ข้อตกลงของผู้จัดการบรรจุภัณฑ์ ซึ่งหมายความว่าพวกเขาไม่ต้องเสียเวลาหารายละเอียดของวิธีการจัดการห้องสมุดในฐานรหัสของคุณ
4. พวกเขาให้วิธีมาตรฐานในการกำหนดเวอร์ชันและแจกจ่ายการอ้างอิงและไฟล์ของคุณเองที่ไม่ได้อยู่ในที่เก็บของคุณ ฉันใช้ประโยชน์จากข้อมูลเหล่านี้สำหรับไฟล์ข้อมูลสแตติกขนาดใหญ่บางแอปพลิเคชันของฉันที่ต้องการดังนั้นจึงทำงานได้ดีสำหรับการกำหนดเวอร์ชันนอกเหนือจากรหัสไบนารี่
5. ผู้จัดการแพ็คเกจบางคนมีคุณสมบัติเพิ่มเติมระหว่างการติดตั้ง NuGet จะเพิ่มการพึ่งพาและไฟล์เนื้อหาลงในไฟล์ csproj ของคุณและยังสามารถเพิ่มองค์ประกอบการกำหนดค่าลงในไฟล์ปรับแต่ง
6. ไฟล์รายการแพ็กเกจของพวกเขาเป็นเอกสารของห้องสมุดของคุณในที่เดียวที่รวมศูนย์ ฉันไม่ต้องคลิกขวาที่ DLL และดูหมายเลขรุ่นเพื่อดูว่าฉันใช้ไลบรารี่รุ่นใด ใน Python ผู้เขียนไลบรารี่อาจไม่ได้รวมหมายเลขเวอร์ชั่นไว้ในไฟล์ py ดังนั้นฉันอาจไม่สามารถบอกเวอร์ชั่นไลบรารี่จากพวกเขาได้
7. พวกเขาไม่สนับสนุนการติดตั้งเครื่องที่กว้างขวาง แพคเกจผู้จัดการให้เป็นวิธีการทั่วไปของการอ้างอิงการติดตั้งโดยไม่ต้องติดตั้งทั่วโลก เมื่อตัวเลือกของคุณคือโฟลเดอร์ lib และการติดตั้งทั่วโลกผู้พัฒนาห้องสมุดหลายคนจะเลือกที่จะให้บริการห้องสมุดหลักเป็นการติดตั้งทั่วโลกแทนที่จะเป็นไบนารีที่สามารถดาวน์โหลดได้ที่คุณต้องตั้งค่าด้วยตัวคุณเอง (ประวัติ MS แสดงให้เห็นถึงสิ่งนี้นอกจากนี้ยังเป็นกรณีของไลบรารีจำนวนมากใน Linux) สิ่งนี้ทำให้การจัดการหลายโครงการยากขึ้นเนื่องจากคุณอาจมีโครงการที่มีเวอร์ชันที่ขัดแย้งกันและนักพัฒนาบางคนจะเลือกการติดตั้งทั่วโลก dir
8. พวกเขามักจะรวมศูนย์การโฮสต์และการกระจาย คุณไม่จำเป็นต้องพึ่งพาเว็บไซต์ของห้องสมุดสุ่มอีกต่อไป หากพวกเขาเลิกกิจการไซต์ของตัวจัดการแพคเกจที่ประสบความสำเร็จยังคงมีทุกรุ่นที่เคยอัปโหลด นักพัฒนายังไม่ต้องค้นหาเว็บไซต์จำนวนมากเพียงเพื่อดาวน์โหลดไลบรารีใหม่ พวกเขามีสถานที่ที่จะไปดูเป็นอันดับแรกและแม้แต่เรียกดูตัวเลือกต่าง ๆ นอกจากนี้ยังง่ายกว่าในการทำมิเรอร์แพ็คเกจที่จัดระเบียบในแบบมาตรฐานมากกว่าโฮสต์สำเนาของทุกสิ่งจากเว็บไซต์ ad-hoc ด้วยตนเอง

คุณกำลังพูดเกินจริงถึงคุณค่าของ "ผลประโยชน์" ของคุณ

1. ไม่ต้องใช้เครื่องมือภายนอกในการจัดการแพ็คเกจ

   "ภายนอก" เพื่ออะไร ฉันตรวจสอบการปฏิบัติการของ NuGet ในที่เก็บของฉัน มันเป็นไบนารีเดียวที่ฉันรู้สึกว่ากำลังเช็คอินเนื่องจากมันมีขนาดเล็กและหมายความว่าฉันไม่จำเป็นต้องตรวจสอบไบนารีอื่น ๆ

   pip ไม่ก่อให้เกิดปัญหาในหน้านี้เนื่องจากมันมาพร้อมกับ Python โดยค่าเริ่มต้นตอนนี้และการแตกหักและถอยหลังที่เข้ากันไม่ได้นั้นหายากอย่างยิ่ง คุณจะไม่พัฒนารหัส Python โดยไม่ต้องติดตั้ง Python ภายนอกกับโครงการของคุณ

   เมื่อถึงการยอมรับอย่างกว้างขวางผู้จัดการแพคเกจมักจะมีเสถียรภาพมาก คุณไม่สามารถรับไปโดยไม่ต้องบางชนิดของการขับรถที่ติดตั้งทั่วโลกสำหรับโครงการส่วนใหญ่และผู้จัดการแพคเกจเดียวเป็นความต้องการน้ำหนักเบาสวย มักจะไม่ยุ่งยากกว่าการติดตั้งรันไทม์ภาษา

2. ไม่จำเป็นต้องสร้างการเชื่อมต่ออินเทอร์เน็ต

   ฉันไม่สามารถเชื่อมต่อกับฐานข้อมูลของฉันได้หากไม่มีการเชื่อมต่อเครือข่าย หากฐานข้อมูลเป็นโฮสต์ของ Amazon ฉันต้องเชื่อมต่ออินเทอร์เน็ตเต็มรูปแบบอยู่ดี ฉันต้องการการเชื่อมต่ออินเทอร์เน็ตเพื่อผลักและดึงการเปลี่ยนแปลงผ่านการควบคุมแหล่งที่มา เซิร์ฟเวอร์การสร้างไม่สามารถตรวจสอบรหัสเพื่อสร้างโดยไม่มีการเชื่อมต่อเครือข่ายบางชนิด คุณไม่สามารถส่งหรือรับอีเมลได้หากไม่มี คุณไม่สามารถดาวน์โหลดไลบรารี่เพื่อใส่ไว้ในโฟลเดอร์ lib ของคุณถ้าไม่มี! การพัฒนาอย่างถาวรโดยไม่ต้องเชื่อมต่ออินเทอร์เน็ตนั้นแทบไม่เคยได้ยินมาก่อน ในบางกรณีที่จำเป็นคุณสามารถจัดการกับสิ่งนี้ได้โดยการดาวน์โหลดแพ็คเกจไปยังตำแหน่งที่ผู้จัดการแพคเกจสามารถใช้งานได้ (ฉันรู้ว่า NuGet และ pip ​​มีความสุขมากที่จะดึงจากโฟลเดอร์หรือไดรฟ์เครือข่ายง่าย ๆ ฉันสงสัยว่าคนอื่น ๆ ส่วนใหญ่สามารถทำได้เช่นกัน)

3. สร้างได้เร็วขึ้น (ไม่มีการตรวจสอบแพ็คเกจ)

   30 วินาทีระหว่างการสร้างอัตโนมัติและ 5 วินาทีในระหว่างการสร้างในพื้นที่นั้นเป็นการแลกเปลี่ยนที่ดีสำหรับผลประโยชน์ที่ฉันได้กล่าวไว้ข้างต้น เหล่านี้เป็นกรอบเวลาเล็ก ๆ น้อย ๆที่มักจะไม่คุ้มค่าเมื่อเทียบกับปัญหาที่ผลประโยชน์แก้ปัญหา

4. สภาพแวดล้อมที่เรียบง่าย (ต้องการความรู้น้อยกว่า)

   หนึ่งเครื่องมือสำหรับการจัดการกับแพคเกจอะไรสำหรับการจัดการห้องสมุดไม่ได้จริงๆเปรียบเทียบยุติธรรมแล้ว หากไม่มีเครื่องมือนี้คุณจะต้องเรียนรู้กระบวนการที่กำหนดเองใด ๆ ที่โครงการใช้เพื่อจัดการห้องสมุด ซึ่งหมายความว่าคุณไม่แน่ใจว่าความรู้ที่มีอยู่ของคุณใช้กับโครงการใหม่ใด ๆ ที่คุณเข้าใกล้หรือไม่ คุณจะต้องจัดการกับสิ่งใดก็ตามที่ผสมเข้าด้วยกันใกล้เข้ามาหรือทำด้วยตัวเอง อาจเป็นไดเร็กตอรี่ที่บรรจุไลบรารี่ทั้งหมดหรือมันอาจจะแปลกไปกว่านี้ อาจหลีกเลี่ยงการตรวจสอบไลบรารีในบางคนนำออกทั้งหมดในไดรฟ์เครือข่ายและตัวบ่งชี้เวอร์ชันเดียวคือชื่อโฟลเดอร์ มันเป็นอย่างไรหรือการติดตั้งทั่วโลกดีขึ้นจริง ๆ ? โดยเปรียบเทียบผู้จัดการแพคเกจช่วยให้คุณมีการประชุมที่สะอาดที่จะใช้กับโครงการส่วนใหญ่ที่คุณพบ

ชุดรูปแบบทั่วไปคือพวกเขาให้ความสอดคล้องเอกสารและคุณลักษณะไม่เพียง แต่ภายในโครงการ แต่แม้แต่ในพวกเขา สิ่งนี้ทำให้ชีวิตของทุกคนง่ายขึ้น

เมื่อเร็ว ๆ นี้ได้ทำการแปลงผลิตภัณฑ์ของเราจากการใช้ไลบรารี่ที่ดาวน์โหลดด้วยตนเองเป็นการจัดการแพ็คเกจอัตโนมัติด้วย Nuget ฉันสามารถพูดได้ว่าการใช้ตัวจัดการแพกเกจมีประโยชน์มากมาย

ผลิตภัณฑ์ของเรามีการใช้งานใน 27 C # โครงการซึ่งค่อนข้างเล็กตามมาตรฐานของวันนี้ การพึ่งพาบุคคลที่สามของเราบางคนมีการชุมนุมหลายสิบ

ก่อนถึง Nuget ถ้าฉันต้องการอัปเดตการอ้างอิงทั้งหมดของเราเป็นเวอร์ชันล่าสุดฉันจะต้อง:

1. ติดตามตำแหน่งที่ฉันสามารถรับไลบรารี่ที่อัพเดตทั้งหมดได้
2. ดาวน์โหลดและเปิดเครื่องรูด / ติดตั้ง
3. เพิ่มเวอร์ชันใหม่เข้ากับแหล่งควบคุม
4. ค้นหาการอ้างอิงทั้งหมดในโครงการของเราด้วยตนเองและอัปเดตพวกเขาให้ชี้ไปที่แอสเซมบลีใหม่

ด้วยโครงการ 27 โครงการและแอสเซมบลีที่ขึ้นต่อกันหลายสิบกระบวนการนี้เกิดข้อผิดพลาดได้ง่ายมากและอาจใช้เวลาหลายชั่วโมง

ตอนนี้เราได้อัปเดตเป็นใช้ Nuget เสร็จแล้วสำหรับฉันด้วยคำสั่งเดียว

ไม่ต้องใช้เครื่องมือภายนอกในการจัดการแพ็คเกจ

มันไม่ใช่ประเด็นใช่ไหม? หากฉันใช้โปรแกรมจัดการแพ็คเกจฉันไม่จำเป็นต้องมีโฟลเดอร์ lib ฉันไม่ต้องจัดการแพ็คเกจด้วยตัวเอง

ไม่จำเป็นต้องสร้างการเชื่อมต่ออินเทอร์เน็ต

นอกเหนือจากที่ไม่มีการเชื่อมต่ออินเทอร์เน็ตในวันนี้ในขณะที่การพัฒนาค่อนข้างหายาก (อาจยกเว้นการขนส่ง) ผู้จัดการแพ็คเกจที่ดีไม่ควรให้คุณต้องมีเวอร์ชันล่าสุดเพื่อสร้างแอปพลิเคชันของคุณ อาจบ่น แต่ไม่มีเหตุผลใดที่จะไม่สร้างด้วยรุ่นที่ติดตั้งไว้แล้ว

สร้างได้เร็วขึ้น (ไม่มีการตรวจสอบแพ็คเกจ)

นั่นเป็น speedboost ที่ไม่สำคัญ แต่คุณสามารถสร้างประเด็นได้

สภาพแวดล้อมที่เรียบง่าย (ต้องการความรู้น้อยกว่า)

ผู้จัดการแพคเกจส่วนใหญ่นั้นง่ายมากในวันนี้ซึ่งแทบจะไม่คุ้มค่าที่จะลองทำสิ่งเหล่านี้ มีแม้กระทั่งลูกค้าที่มองเห็นถ้าคุณต้องการ พวกเขาซ่อน croft มากมายที่เกิดขึ้นจริง ๆ

ผู้จัดการแพ็คเกจยังอนุญาตให้คุณแชร์แพ็คเกจเหล่านี้ระหว่างโครงการต่างๆ หาก 5 โครงการของฉันใช้ Boost รุ่นเดียวกันไม่จำเป็นต้องทำซ้ำสิ่งนี้สำหรับแต่ละโครงการ นี่คือความจริงโดยเฉพาะอย่างยิ่งสำหรับต้นไม้พึ่งพาที่ซับซ้อนที่คุณพูดถึง

ด้วยโฟลเดอร์ lib คุณจัดการแพ็กเกจสำหรับโครงการนั้นเท่านั้นในขณะที่ตัวจัดการแพคเกจช่วยให้คุณทำสิ่งนี้สำหรับสภาพแวดล้อมการพัฒนาทั้งหมดของคุณด้วยเครื่องมือเดียว

มันเป็นความแตกต่างระหว่างการใช้ไลบรารี(ไดเรกทอรี lib)และการใช้งานโดยคงไว้ซึ่งข้อมูลเมตา (แพคเกจผู้จัดการ) ข้อมูลเมตาดังกล่าวเกี่ยวข้องกับหมายเลขรุ่นการอ้างอิง (สกรรมกริยา) ระหว่างไลบรารีและเช่นนั้น

การอภิปรายเกี่ยวกับ DLL Hell, ความเข้ากันได้กับไลบรารี, ระบบโมดูล java, OSGi และอย่างน้อยก็ควรมีความเชื่อมั่นเพียงพอต่อการมีรูปแบบของการจัดการการพึ่งพา

• ปัญหาเกี่ยวกับเวอร์ชันไลบรารีและการพึ่งพาอาจเป็นเรื่องเสียเวลา

นอกจากนี้ยังมีประโยชน์ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน (ท้องถิ่น) ดังนั้นหลายโครงการไม่จำเป็นต้องเก็บสำเนาของ libs ที่นำเข้า หากมีโครงการที่มี 20 submodules บางส่วนของโมดูลเหล่านั้นมี 40 อ้างอิงที่แปลก

• โครงสร้างเพิ่มเติม
• ตัดแต่งห้องสมุดมากขึ้น
• ไม่มีการตัดสินใจของมนุษย์แบบเฉพาะกิจเกี่ยวกับห้องสมุด

มีบางกรณีที่อาจจำเป็นต้องใช้โฟลเดอร์ lib เช่นเมื่อต้องจัดการกับไลบรารีที่ล้าสมัย (เวอร์ชันของมันไม่มีการดูแล / ใช้งานได้อีกต่อไป), เวอร์ชันที่ปรับเปลี่ยนในเครื่องของไลบรารี ...

แต่สำหรับทุกอย่างมันก็เหมือนกับนักพัฒนาที่สมมติบทบาทของผู้จัดการแพ็คเกจ:

• ผู้พัฒนาจะต้องดาวน์โหลดไลบรารี (ต้องการอินเทอร์เน็ต)
• นักพัฒนาจะต้องตรวจสอบรุ่นใหม่ด้วยตนเอง
• ...

และ IMHO มันจำเป็นต้องมีความรู้น้อยกว่าเพราะคุณต้องเรียนรู้เกี่ยวกับการใช้งานเครื่องมือภายนอก แต่น้อยกว่าเกี่ยวกับไลบรารี (เช่นการพึ่งพา)

มีปัญหาอื่นที่ไม่ครอบคลุมโดยคำถามอื่น ๆ : การแบ่งปัน deps

สมมติว่าคุณมีสองแพ็คเกจที่สร้างไลบรารี่เดียวกัน ในกรณีที่ดีที่สุดจะไม่มี coflicts ใด ๆ แต่มีการใช้พื้นที่ HDD / SSD เดียวกันสองครั้ง สิ่งที่แย่ที่สุดก็คือจะมีความขัดแย้งของ Varios เหมือนเวอร์ชั่น

หากคุณใช้ตัวจัดการแพคเกจมันจะติดตั้งไลบรารี่เพียงครั้งเดียว (ต่อเวอร์ชั่น) และระบุเส้นทางไปยังมันแล้ว

PS: แน่นอนคุณต้องเชื่อมโยงแบบไดนามิก (หรือฟังก์ชั่นที่คล้ายกันในภาษาของคุณ) เพื่อรับโปรนี้

เหตุผลสำคัญข้อหนึ่งที่ว่าทำไมไลบรารีที่ใช้ร่วมกันถูกพิจารณาว่าเป็นรายการความคืบหน้าในยุค 90 ของระบบ Unix และ Windows คือวิธีที่พวกเขาสามารถลดการใช้ RAM ได้เมื่อมีหลายโปรแกรมที่ใช้ไลบรารีชุดเดียวกันถูกโหลด รหัสพื้นที่จะต้องจัดสรร ONCE ต่อไลบรารี่ที่แน่นอนและเวอร์ชันของไลบรารี่นั้น ๆนั้นการใช้หน่วยความจำต่ออินสแตนซ์ที่เหลืออยู่สำหรับตัวแปรแบบคงที่เท่านั้น

ระบบปฏิบัติการหลายระบบใช้ไลบรารีที่แบ่งใช้ในลักษณะที่ขึ้นอยู่กับกลไกเช่น unix mmap () api ซึ่งหมายความว่าไลบรารีไม่เพียง แต่ต้องเป็นเวอร์ชันเดียวกันเท่านั้น แต่จริงๆแล้วเป็นไฟล์เดียวกัน นี่เป็นไปไม่ได้เลยที่จะใช้ประโยชน์จากโปรแกรมที่จัดส่งไลบรารี่ของตนเอง

เนื่องจากหน่วยความจำนั้นมีราคาถูกกว่ามากและรุ่นไลบรารี่จำเป็นต้องมีความหลากหลายมากกว่าในยุค 90 อาร์กิวเมนต์นี้ไม่ได้มีน้ำหนักมากในปัจจุบัน