ปัญหา Flat Namespace ของ Rust จุดประกายการถอดเถียงในชุมชนเกี่ยวกับการแก้ไขปัญหาการจัดการแพ็กเกจ

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

ตัวอย่าง Rust Packages ที่ได้รับผลกระทบ:

• ffmpeg → ffmpeg-next → ffmpeg-the-third, rffmpeg
• spectral → speculoos
• onnxruntime-rs → ort
• leaf → juice
• yaml-rust → yaml-rust2
• serde-yaml → serde-yaml-bw

สาเหตุหลัก: การออกแบบ Flat Namespace

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

แนวทางของ Go เสนอทางเลือกที่น่าสนใจ โดยแพ็กเกจจะถูกระบุด้วย import path แบบเต็มเช่น github.com/user/package-name ซึ่งหมายความว่านักพัฒนาหลายคนสามารถสร้างแพ็กเกจที่มีชื่อฐานเดียวกันภายใต้ path ที่แตกต่างกัน ทำให้ไม่มีความขัดแย้งในเรื่อง namespace เลย เมื่อแพ็กเกจถูกทิ้งร้าง การ fork สามารถรักษาชื่อเดิมไว้ได้โดยเพียงแค่เปลี่ยน import path

วิธีแก้ไขเชิงเทคนิคและข้อจำกัด

แม้ว่า Rust จะรองรับทางเลือกอื่นๆ สำหรับ flat namespace ผ่าน git-based dependencies และ alternative registries แต่วิธีแก้ไขเหล่านี้มีข้อจำกัดในทางปฏิบัติ นักพัฒนาสามารถระบุ dependencies โดยตรงจาก git repositories หรือใช้ custom registries ได้ แต่ crate ที่เผยแพร่บน crates.io ไม่สามารถพึ่งพาแพ็กเกจจาก registry อื่นได้ ข้อจำกัดนี้ทำให้ระบบนิเวศส่วนใหญ่ยังคงผูกติดกับข้อจำกัดในการตั้งชื่อของ registry หลัก

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

การเรียนรู้จากระบบนิเวศอื่นๆ

แนวทางของระบบนิเวศ Java Maven ที่ใช้ group identifier, artifact identifier และ classifier ให้แบบจำลองอื่นสำหรับการตั้งชื่อแพ็กเกจแบบลำดับชั้น ระบบนี้ซึ่งได้รับการพิสูจน์มาหลายทศวรรษ ป้องกันความขัดแย้งใน namespace ที่รบกวนระบบการตั้งชื่อแบบเรียบ สมาชิกในชุมชนหลายคนสังเกตว่าแนวทางแบบเก่าเหล่านี้จาก Java และ .NET มีบทเรียนที่มีค่าสำหรับระบบนิเวศภาษาใหม่ๆ

หากภาษาใหม่ๆ ได้ทำตามวิธี Java Maven แบบเก่าๆ ที่มีสามส่วน: groupId, artifactId และ classifier สำหรับไลบรารี ปัญหาเหล่านี้ก็จะไม่เกิดขึ้น

การเปรียบเทียบระบบการตั้งชื่อทางเลือก:

เส้นทางไปข้างหน้า

แม้ว่าวิธีแก้ไขเชิงองค์กรเช่น GitHub organizations ที่จัดการโดยชุมชนของ Julia จะให้ความช่วยเหลือบ้าง แต่ก็ไม่ได้แก้ไขข้อจำกัดทางเทคนิคพื้นฐานของระบบแพ็กเกจของ Rust การอภิปรายนี้เน้นย้ำถึงความจำเป็นในการเปลี่ยนแปลงที่เป็นพื้นฐานมากขึ้นในวิธีที่ Rust จัดการกับการตั้งชื่อแพ็กเกจและการจัดการ dependency

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

อ้างอิง: What Julia has that Rust desperately needs