การตรวจสอบ Reverse Dependency ของ CRAN ท้าทายแนวทางการจัดการแพ็กเกจแบบดั้งเดิม

ระบบนิเวศการเขียนโปรแกรม R ได้จุดประกายการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนาด้วยแนวทางที่เป็นเอกลักษณ์ในการจัดการแพ็กเกจ ไม่เหมือนกับระบบดั้งเดิมที่นักพัฒนาสามารถเผยแพร่การอัปเดตได้อย่างอิสระ CRAN ( Comprehensive R Archive Network ) ต้องการการทดสอบอย่างละเอียดที่เกินกว่าการตรวจสอบคุณภาพทั่วไป

ปรัชญา Monorepo ในการปฏิบัติ

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

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

CRAN เทียบกับ Package Managers แบบดั้งเดิม

การเปลี่ยนแปลงที่ทำลายต้องการการทำลายอุปสรรค

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

อีกวิธีหนึ่งในการมองเรื่องนี้คือสิ่งเหล่านี้คือลูกค้าของ API ของแพ็กเกจของคุณ หากคุณทำลายพวกเขา คุณจำเป็นต้องส่งมอบการแก้ไข

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

ความท้าทายในการนำไปใช้ทางเทคนิค

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

นักพัฒนาบางคนได้เสนอโซลูชันที่ได้แรงบันดาลใจจากระบบนิเวศอื่นๆ เช่น เครื่องมือการย้ายโค้ดอัตโนมัติ หรือแพทช์ชั่วคราวที่รักษาความเข้ากันได้ระหว่างการเปลี่ยนผ่าน ไอเดียเหล่านี้ได้รับแรงบันดาลใจจากการนำไปใช้ที่ประสบความสำเร็จในบริษัทต่างๆ เช่น Jane Street ที่การเปลี่ยนแปลงที่ทำลายจะกระตุ้นการอัปเดตอัตโนมัติทั่วทั้งโค้ดเบส

ความท้าทายทางเทคนิคหลักที่กล่าวถึง

• การประสานงานการพึ่งพา: แพ็กเกจยอดนิยมอย่าง glmnet ต้องประสานงานกับการพึ่งพาแบบย้อนกลับมากกว่า 150+ รายการ
• ความซับซ้อนของการย้าย API: การเปลี่ยนแปลงครั้งใหญ่ต้องการการอัปเดตโค้ดข้ามหลายแพ็กเกจที่ไม่เกี่ยวข้องกัน
• ข้อจำกัดด้านขนาด: วิธีการนี้ใช้ได้ผลกับขนาดของระบบนิเวศของ R แต่อาจไม่สามารถขยายขนาดไปยังกราฟการพึ่งพาที่ใหญ่กว่าได้
• ช่องว่างในการทำงานอัตโนมัติ: ระบบปัจจุบันขาดความสามารถในการ commit แบบอะตอมิกของ monorepos จริง

ผลกระทบที่กว้างขึ้นต่อการพัฒนาซอฟต์แวร์

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

การแลกเปลี่ยนกลายเป็นสิ่งที่ชัดเจนเมื่อเปรียบเทียบ R กับระบบนิเวศอื่นๆ ที่ประสบปัญหา dependency hell และโปรเจ็กต์ที่ถูกทิ้งร้างติดอยู่กับเวอร์ชันที่ล้าสมัย แนวทางของ CRAN อาจทำให้นักพัฒนาแพ็กเกจหงุดหงิด แต่มันส่งมอบคำมั่นสัญญาที่ผู้ใช้สามารถอัปเดตทุกอย่างและทำงานต่อไปได้

การถกเถียงเน้นย้ำคำถามพื้นฐานในการพัฒนาซอฟต์แวร์: ภาระของความเข้ากันได้ควรตกอยู่กับผู้เขียนแพ็กเกจหรือผู้ใช้? คำตอบของ CRAN วางความรับผิดชอบไว้กับนักพัฒนาอย่างชัดเจน สร้างระบบนิเวศที่เสถียรกว่าแต่อาจเคลื่อนไหวช้ากว่าที่ให้ความสำคัญกับประสบการณ์ผู้ใช้มากกว่าความสะดวกของนักพัฒนา

อ้างอิง: If all the world were a monorepo