บทความล่าสุดที่แสดงให้เห็นวิธีการใช้ Make สำหรับการจัดการ dotfiles ได้จุดประกายการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนาเกี่ยวกับแนวทางที่ดีที่สุดในการจัดการไฟล์คอนฟิกูเรชัน การอภิปรายครั้งนี้เผยให้เห็นความแตกแยกที่น่าสนใจระหว่างผู้ที่ชื่นชม Make ในด้านความแพร่หลายและผู้ที่ชอบทางเลือกที่เรียบง่ายกว่า
ความขัดแย้งเรื่องความเรียบง่าย
ความไม่เห็นด้วยหลักมีจุดศูนย์กลางอยู่ที่สิ่งที่ถือว่าเรียบง่ายในการพัฒนาซอฟต์แวร์ ในขณะที่บทความต้นฉบับนำเสนอ Make เป็นโซลูชันที่ง่ายอย่างน่าประหลาดใจสำหรับการจัดการ dotfile นักวิจารณ์โต้แย้งว่าฟีเจอร์ขั้นสูงของ Make ที่แสดงให้เห็นนั้นทำให้งานที่ควรจะตรงไปตรงมากลับซับซ้อนขึ้น โซลูชันที่เสนอใช้ความสามารถด้าน metaprogramming ของ GNU Make และตัวแปรอัตโนมัติเพื่อสร้าง symbolic links ระหว่าง dotfiles repository และ home directory
นักพัฒนาหลายคนได้โต้กลับด้วยทางเลือก shell script ที่สามารถทำงานเดียวกันได้ด้วยโค้ดที่น้อยกว่า ทางเลือกเหล่านี้ใช้เครื่องมือ Unix พื้นฐานอย่าง find
, sed
, และ xargs
เพื่อสร้าง symbolic links ที่จำเป็นโดยไม่ต้องมีความรู้เกี่ยวกับฟีเจอร์ที่ลึกซึ้งกว่าของ Make
ทางเลือก Shell Script พื้นฐาน (3 บรรทัด):
files=$(find files -type f | sed s=^files/==)
echo "$files" | sed s=[^/]*\$== | sort -u | { cd; xargs mkdir -p; }
echo "$files" | xargs -I{} -n1 ln -sf $PWD/files/{} ~/{}
ปัจจัยด้านความแพร่หลาย
จุดสำคัญที่สนับสนุน Make คือความพร้อมใช้งานอย่างกว้างขวาง เกือบทุกระบบที่สามารถคอมไพล์ซอฟต์แวร์ได้จะมี Make ทำให้ไม่จำเป็นต้องติดตั้งเครื่องมือเพิ่มเติม ข้อได้เปรียบนี้มีค่าเป็นพิเศษในสภาพแวดล้อมที่การติดตั้งซอฟต์แวร์ใหม่ต้องได้รับการอนุมัติหรือเมื่อทำงานบนระบบที่มีขนาดเล็ก
อย่างไรก็ตาม นักวิจารณ์ชี้ให้เห็นว่า shell scripts มีความแพร่หลายมากกว่า GNU Make เนื่องจากฟังก์ชันพื้นฐานของ shell มีอยู่ในเกือบทุกระบบที่คล้าย Unix การถกเถียงนี้เน้นให้เห็นว่านักพัฒนาต่างคนให้ความสำคัญกับแง่มุมต่างๆ ของโซลูชันสากลอย่างไร
ทางเลือกสมัยใหม่ได้รับความนิยมเพิ่มขึ้น
การอภิปรายยังเผยให้เห็นความนิยมที่เพิ่มขึ้นของเครื่องมือจัดการ dotfile เฉพาะทาง Nix กับ Home Manager โดดเด่นขึ้นมาเป็นโซลูชันที่ได้รับความนิยมเป็นพิเศษในหมู่ผู้ใช้ขั้นสูง โดยเสนอการจัดการคอนฟิกูเรชันแบบ declarative ที่ไปไกลกว่าการเชื่อมโยงไฟล์อย่างง่าย แม้ว่า Nix จะให้ความสามารถที่น่าประทับใจ แต่ก็มาพร้อมกับเส้นโค้งการเรียนรู้ที่สูงชันและความซับซ้อนอย่างมาก
ไม่มีอะไรเทียบได้กับ nix + home manager แต่ก็สนุกที่ได้เห็นว่าคนเราใช้วิธีต่างๆ กันมากมายแค่ไหนในการแก้ปัญหาเฉพาะนี้
เครื่องมืออื่นๆ ที่ถูกกล่าวถึงรวมถึง Chezmoi, yadm, และ GNU Stow แต่ละตัวเสนอแนวทางที่แตกต่างกันสำหรับปัญหาพื้นฐานเดียวกัน นักพัฒนาบางคนชอบเครื่องมือที่สร้างขึ้นเพื่อจุดประสงค์เฉพาะเหล่านี้แม้จะมีภาระการติดตั้งเพิ่มเติม โดยอ้างถึงประสบการณ์ผู้ใช้ที่ดีกว่าและฟีเจอร์ที่ซับซ้อนกว่า
แนวทางการจัดการ Dotfile ที่ได้รับความนิยม:
เครื่องมือ/วิธีการ | ข้อดี | ข้อเสีย |
---|---|---|
Make | มีอยู่ทั่วไป มีโครงสร้าง ค้นหาได้ง่าย | ไวยากรณ์ซับซ้อน ใช้มากเกินไปสำหรับงานง่ายๆ |
Shell Scripts | เรียบง่าย ใช้ได้ทั่วไป ต้องการ dependency น้อย | โครงสร้างน้อย ดูแลรักษายาก |
Nix + Home Manager | แบบ declarative มีพลัง สามารถทำซ้ำได้ | เรียนรู้ยาก ตั้งค่าซับซ้อน |
Chezmoi | สร้างมาเพื่อจุดประสงค์นี้โดยเฉพาะ มีฟีเจอร์มากมาย | ต้องติดตั้งเพิ่มเติม |
GNU Stow | การจัดการ symlink ที่เรียบง่าย | ฟังก์ชันการทำงานจำกัด |
yadm | ใช้ Git เป็นฐาน รองรับ bootstrap | ต้องพึ่งพา Git |
ปรากฏการณ์ Task Runner
การอภิปรายด้านข้างที่น่าสนใจเกิดขึ้นเกี่ยวกับการใช้ Make เป็น task runner อเนกประสงค์มากกว่าระบบ build นักพัฒนาหลายคนชื่นชมฟีเจอร์ความสามารถในการค้นพบและการเติมข้อความด้วย tab ของ Make ทำให้ง่ายต่อการดูคำสั่งที่มีอยู่ในโปรเจ็กต์ใดๆ รูปแบบการใช้งานนี้กลายเป็นเรื่องธรรมดาแม้ว่า Make จะถูกออกแบบมาเป็นเครื่องมือ build ที่ติดตาม dependency
การถกเถียงสะท้อนแนวโน้มที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ ที่นักพัฒนาต้องสร้างสมดุลระหว่างความเรียบง่าย ฟังก์ชันการทำงาน และความสามารถในการบำรุงรักษาเมื่อเลือกเครื่องมือ ในขณะที่บางคนชอบแนวทางมินิมัลลิสต์ของ shell scripts คนอื่นๆ ให้ค่ากับแนวทางที่มีโครงสร้างของ Make หรือฟีเจอร์ครอบคลุมของเครื่องมือเฉพาะทางสมัยใหม่
อ้างอิง: Managing dotfiles with Make