เหตุใดไลบรารีจึงถูกส่งแยกต่างหากแทนที่จะรวมกับทุกโปรแกรม

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

ฉันสามารถใช้เหตุผลอะไรในการโน้มน้าวพวกเขา

สถานการณ์ที่เฉพาะเจาะจงของฉันคือ: ฉันกำลังทำงานกับSymPyซึ่งเป็นห้องสมุดโอเพ่นซอร์สสำหรับคณิตศาสตร์เชิงสัญลักษณ์ ส่วนหลักของมันคือmpmathซึ่งเป็นห้องสมุดสำหรับเลขคณิตจุดลอยตัวหลายฝ่าย SymPy ไม่ทำงานหากไม่มี mpmath ไม่มีทางเลือกอื่น ดังนั้นมันจึงถูกรวมเข้ากับ SymPy ตั้งแต่เริ่มต้น (ฉันได้รับแจ้งว่ามักจะมีความเข้ากันไม่ได้เล็กน้อยในการแก้ไขทุกครั้งที่มีการนำเข้าเวอร์ชันใหม่) ควรสังเกตว่าผู้พัฒนา mpmath เคยมีส่วนร่วมในการพัฒนา SymPy ขณะนี้มีปัญหาใน mpmath unbundling คุณสามารถอ่านมันทั้งหมดที่นี่

เพื่อสรุปการอภิปรายที่นั่น:

unbundle:

• การย้ายไปยัง Python 3 ง่ายกว่า (มีอาร์กิวเมนต์เล็กน้อย IMHO)

• บรรจุภัณฑ์ที่ง่ายขึ้นสำหรับการแจกแจง

• อัปเดตฟีเจอร์ที่เร็วขึ้น (ความปลอดภัย) ให้กับผู้ใช้

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

ให้บันเดิล:

• การติดตั้ง. มันง่ายบน Linux, ยากกว่าบน Mac และยากมากบน Windows การขาดการเข้าถึง su และปัญหาอื่น ๆ

• มันเป็นส่วนสำคัญของ SymPy เช่น sympy ไม่ทำงานโดยไม่ได้ (เลย)

• มีไม่มีแพคเกจอื่น ๆ ที่สามารถทำผลงานของ mpmath

• "เมื่อฉันในฐานะผู้ใช้ดาวน์โหลด sympy ฉันคาดหวังให้มันใช้งานได้"

นั่นเป็นสถานการณ์เฉพาะของฉัน แต่ฉันยอมรับคำตอบที่ให้คำตอบที่ดีและเป็นคำตอบทั่วไป

อีกคำตอบหนึ่ง แต่ฉันคิดว่าเป็นสิ่งที่สำคัญที่สุด (แค่ความเห็นส่วนตัวของตัวเอง) แต่คนอื่นก็เป็นคำตอบที่ดีเช่นกัน

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

นอกเหนือจากข้อดีที่คุณกล่าวถึง (ความปลอดภัยบรรจุภัณฑ์คุณสมบัติ) ฉันสามารถนึกถึงบางอย่างเพิ่มเติมได้ที่:

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

• ในกรณีที่การทำเช่นนี้มีประโยชน์สำหรับโครงการอื่น ๆ สิ่งนี้จะลดขนาดการใช้งานดิสก์โดยทั่วไป (เช่นเพียงหนึ่งสำเนาของรหัส)

• วิธีนี้จะช่วยปรับปรุงคุณภาพของรหัสของคุณบังคับให้คุณทำการปรับโครงสร้างบางส่วน (จำเป็นมาก) เช่นเดียวกับในจุดแรกข้างต้นสิ่งนี้ขึ้นอยู่กับคุณภาพของรหัสของคุณ

• การเพิ่มจำนวนผู้ใช้ห้องสมุด (ถ้าแยกออก) จะช่วยทำให้เป็นเรื่องทั่วไปมากขึ้นซึ่งน่าจะปรับปรุงคุณภาพของห้องสมุดด้วย

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

ต่อไปนี้เป็นข้อโต้แย้งเพิ่มเติมเกี่ยวกับการรวมกลุ่ม:

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

• ใน Windows และ Mac OS มักใช้ตัวจัดการแพคเกจของ Python เช่น pip เนื่องจากการติดตั้งไลบรารีด้วยมือนั้นยุ่งยาก

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

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

• คนมักจะเกลียดเมื่อโปรแกรมคิดว่าตัวเองฉลาดกว่าพวกเขา ให้ผู้ใช้ดูแลระบบของตัวเอง

ที่เหมาะสมกับวิธีการจัดการกลุ่มไว้ในหน้าต่างติดตั้งแพคเกจจะมีการทดสอบ Preinst สำหรับการดำรงอยู่ของห้องสมุดและถ้ามันไม่ได้อยู่ที่จะนำเสนอในการติดตั้งจากแพคเกจไลบรารีที่คุณรวมอยู่ในแพคเกจติดตั้งซอฟแวร์ ฉันค่อนข้างมั่นใจว่าแอพ GTK ส่วนใหญ่ที่มีพอร์ต windows ทำบางอย่างตามบรรทัดเหล่านี้ - ฉันรู้ว่าpidginทำ

ขนาดเดียวไม่จำเป็นต้องพอดีทั้งหมด

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

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

แต่ไม่มีเหตุผลใดที่คุณไม่สามารถทำการตัดสินใจและมัดรวมสำหรับตัวติดตั้ง Windows และ Mac ได้

การมัดรวมกับการขึ้นอยู่กับการถกเถียงที่เก่าแก่ในโลกของบรรจุภัณฑ์ เอกสารนี้บอกเกี่ยวกับโรงเรียนแห่งความคิดสองแห่งนี้: http://www.aosabook.org/en/packaging.html