การถกเถียงที่เพิ่มขึ้นในชุมชนนักพัฒนาได้เกิดขึ้นเกี่ยวกับว่าเครื่องมือ command-line ควรเก็บไฟล์การกำหนดค่าไว้ที่ไหนใน macOS ไลบรารีโปรแกรมยอดนิยมหลายตัวกำลังวางไฟล์การกำหนดค่า CLI ใน ~/Library/Application Support อย่างไม่ถูกต้อง ทำให้เกิดความหงุดหงิดในหมู่นักพัฒนาที่คาดหวังให้ไฟล์เหล่านี้ปฏิบัติตาม XDG Base Directory Specification และอยู่ใน ~/.config
ปัญหานี้เกิดจากไลบรารีที่ใช้กันอย่างแพร่หลายที่กำหนดไดเร็กทอรีการกำหนดค่าเฉพาะแพลตฟอร์ม แพ็กเกจ platformdirs ของ Python (ดาวน์โหลด 242 ล้านครั้งต่อเดือน), env-paths ของ JavaScript (ดาวน์โหลด 95 ล้านครั้งต่อเดือน), dirs crate ของ Rust (ดาวน์โหลด 4.8 ล้านครั้งต่อเดือน) และแพ็กเกจ adrg/xdg ของ Go ทั้งหมดใช้ค่าเริ่มต้นเป็น ~/Library/Application Support บน macOS สิ่งนี้ส่งผลกระทบต่อเครื่องมือ command-line หลายร้อยตัวที่พึ่งพาไลบรารีเหล่านี้สำหรับการจัดการการกำหนดค่า
ไลบรารียอดนิยมที่ใช้ไดเรกทอรีผิด:
- Python's platformdirs : ดาวน์โหลด 242 ล้านครั้งต่อเดือน
- JavaScript's env-paths : ดาวน์โหลด 95 ล้านครั้งต่อเดือน
- Rust's dirs crate : ดาวน์โหลด 4.8 ล้านครั้งต่อเดือน
- Go's adrg/xdg package : ถูกใช้งานใน 913 แพ็กเกจ
รากเหง้าของปัญหา
ความสับสนเกิดจากการตีความแนวทาง macOS Standard Directories ของ Apple อย่างผิดๆ แนวทางเหล่านี้อ้างถึงแอปโดยเฉพาะ - ซึ่งใน macOS หมายถึง Application Bundles ที่มีส่วนขยาย .app, bundle identifiers และข้อกำหนดการติดตั้งเฉพาะ เครื่องมือ command-line แตกต่างจากแอปโดยพื้นฐานและไม่มีลักษณะเหล่านี้
เอกสารของ Apple ระบุอย่างชัดเจนว่า Application Support ควรมีไฟล์ที่แอปสร้างและจัดการในนามของผู้ใช้ และควรจัดระเบียบโดยใช้ bundle identifiers เนื่องจากเครื่องมือ CLI ไม่มี bundle identifiers และไฟล์การกำหนดค่าของพวกมันมักจะถูกแก้ไขด้วยมือโดยผู้ใช้ จึงไม่เข้าข่ายหมวดหมู่นี้
ความคาดหวังของนักพัฒนา vs ความเป็นจริง
ความหงุดหงิดของชุมชนเห็นได้ชัดในการอภิปรายที่กำลังดำเนินอยู่รอบๆ ไลบรารียอดนิยม นักพัฒนา Rust ได้ขอให้เปลี่ยนแปลง dirs crate หลายครั้ง แต่ผู้ดูแลปฏิเสธที่จะรองรับมาตรฐาน XDG บน macOS สิ่งนี้ทำให้นักพัฒนาบางคนละทิ้งไลบรารีไปเลย สร้างโซลูชันแบบกำหนดเองที่ใช้ข้อกำหนด XDG อย่างถูกต้องข้ามแพลตฟอร์ม
ในฐานะผู้ใช้ใหม่ มันน่าแปลกใจมากสำหรับฉันที่เครื่องมือสมัยใหม่อย่าง nu จะใส่ไฟล์การกำหนดค่าไว้ใต้ Application Support บน macOS มันยิ่งน่าแปลกใจกว่านั้นที่เห็นว่าบางคนต่อต้านการใช้มาตรฐาน XDG อย่างแข็งขัน
ความคาดหวังสำหรับ ~/.config ไม่ใช่เรื่องเอาแต่ใจ - มันอิงจากความสอดคล้องกับระบบ Unix-like อื่นๆ และความจริงที่ว่า macOS เป็นระบบปฏิบัติการ Unix ที่ได้รับการรับรอง แม้แต่เครื่องมือ command-line ของ Apple เอง เช่น bash, zsh, git และ vim ก็ปฏิบัติตามแบบแผน Unix แบบดั้งเดิมสำหรับการวางไฟล์การกำหนดค่า
เครื่องมือจัดการ Dotfile เผยความต้องการของผู้ใช้
เครื่องมือจัดการ dotfile ยอดนิยมให้ข้อมูลเชิงลึกเกี่ยวกับพฤติกรรมจริงของผู้ใช้ เครื่องมืออย่าง chezmoi (14.3k ดาวบน GitHub), dotbot (7.3k ดาว) และ yadm (5.5k ดาว) ไม่พยายามรองรับ ~/Library/Application Support โดยค่าเริ่มต้น แม้จะรวมการกำหนดค่าเฉพาะ macOS ไว้ด้วย สิ่งนี้บ่งชี้ว่าผู้ใช้ส่วนใหญ่คาดหวังและจัดการการกำหนดค่า CLI ของพวกเขาในตำแหน่ง Unix มาตรฐาน
จำนวน GitHub Stars ของเครื่องมือจัดการ Dotfile:
- chezmoi: 14.3k ดาว
- dotbot: 7.3k ดาว
- yadm: 5.5k ดาว
- rcm: 3.2k ดาว
โซลูชัน XDG
XDG Base Directory Specification เสนอโซลูชันที่สะอาดซึ่งทำงานข้ามระบบ Unix-like รวมถึง macOS มันให้ตำแหน่งมาตรฐานสำหรับการกำหนดค่า ($XDG_CONFIG_HOME), cache ($XDG_CACHE_HOME) และไฟล์ข้อมูล พร้อมค่าเริ่มต้นที่สมเหตุสมผลเมื่อไม่ได้ตั้งค่าตัวแปรสภาพแวดล้อม
นักพัฒนาบางคนได้พบวิธีแก้ปัญหาโดยใช้ไลบรารีทางเลือกอย่าง etcetera crate ใน Rust ซึ่งใช้มาตรฐาน XDG ทั้งบน Linux และ macOS โดยค่าเริ่มต้น คนอื่นๆ ได้สร้างการใช้งานแบบกำหนดเองที่เคารพตัวแปรสภาพแวดล้อม XDG เมื่อมีการตั้งค่าไว้ ให้ผู้ใช้ควบคุมการวางตำแหน่งการกำหนดค่าของพวกเขา
การใช้ไดเรกทอรีการกำหนดค่าที่ถูกต้อง:
- เครื่องมือ CLI: ควรใช้
~/.config(ข้อกำหนด XDG ) - แอป GUI ใน /Applications: สามารถใช้
~/Library/Application Support - การตั้งค่า macOS: ควรใช้
~/Library/Preferencesกับ NSDefaults API
การก้าวไปข้างหน้า
โซลูชันไม่ซับซ้อน - เครื่องมือ command-line ควรปฏิบัติตามข้อกำหนด XDG โดยใช้ค่าเริ่มต้นเป็น ~/.config สำหรับไฟล์การกำหนดค่าบนระบบ Unix-like รวมถึง macOS สำหรับแอปพลิเคชัน GUI ที่ติดตั้งใน /Applications ที่จัดการการกำหนดค่าโดยอัตโนมัติ ~/Library/Application Support ยังคงเหมาะสม
การถกเถียงนี้เน้นย้ำปัญหาที่กว้างขึ้นในการพัฒนาข้ามแพลตฟอร์ม: ความสำคัญของการเข้าใจแนวทางเฉพาะแพลตฟอร์มในบริบทที่เหมาะสมแทนที่จะนำไปใช้กับซอฟต์แวร์ทุกประเภทอย่างไม่คิด ขณะที่ชุมชนนักพัฒนายังคงผลักดันเพื่อความสอดคล้องและค่าเริ่มต้นที่เป็นมิตรต่อผู้ใช้ ผู้ดูแลไลบรารีอาจต้องพิจารณาการใช้งานปัจจุบันของพวกเขาใหม่เพื่อตอบสนองความต้องการที่แท้จริงของผู้ใช้ได้ดีขึ้น
อ้างอิง: macOS dotfiles should not go in ~/Library/Application Support