Show HN: Lux – Lux ตัวจัดการแพ็กเกจขั้นสูงสำหรับ Lua

• Lux เป็นตัวจัดการแพ็กเกจใหม่สำหรับการสร้าง ดูแลรักษา และเผยแพร่โค้ด Lua โดยมีเป้าหมายเพื่อสร้างระบบนิเวศที่เหมาะกับ Lua
• Lux มี CLI ที่เรียบง่ายและใช้งานได้อย่างเป็นธรรมชาติ โดยได้แรงบันดาลใจจากตัวจัดการแพ็กเกจที่เป็นที่รู้จักอย่าง cargo

ฟีเจอร์

• พกพาข้ามระบบได้อย่างสมบูรณ์
• รองรับการบิลด์และติดตั้งแบบขนาน 🚀
• จัดการการติดตั้ง Lua headers ให้อัตโนมัติ
• เปิดเผย Lua API ได้ผ่าน lux-lib crate
• จัดการโปรเจ็กต์ผ่านไฟล์ lux.toml
• สร้าง rockspec อัตโนมัติ
• รองรับ lockfile อย่างแข็งแกร่ง
• บิลด์และสภาพแวดล้อมสำหรับพัฒนาที่ทำซ้ำได้อย่างสมบูรณ์
• ผสานรวมการจัดรูปแบบโค้ดและ linting
• รองรับการรันทดสอบผ่าน busted
• สามารถใช้ Neovim เป็น Lua interpreter ได้
• ตั้งค่าสภาพแวดล้อมแบบบริสุทธิ์
• เข้ากันได้กับระบบนิเวศ luarocks

แรงจูงใจ

Lua

• Luarocks มีประวัติยาวนาน 20 ปี จึงไม่เหมาะกับการพัฒนา Lua สมัยใหม่
• Lux มีเป้าหมายที่จะเป็นการเริ่มต้นใหม่
  • ใช้ TOML เป็นรูปแบบ manifest หลักสำหรับจัดการ dependencies
  • สามารถบิลด์และติดตั้งโปรเจ็กต์จากไดเรกทอรีของโปรเจ็กต์ด้วยคำสั่ง build
  • บังคับให้ปฏิบัติตาม SemVer
  • รองรับการบิลด์แบบขนาน

Neovim

• ได้รับความนิยมเพิ่มขึ้นจากการรองรับ Luarocks ของตัวจัดการปลั๊กอิน Neovim อย่าง rocks.nvim และ lazy.nvim
• Lux ไม่ทำลายโครงสร้างเดิมและไม่แทรกแซงวิธีเผยแพร่ปลั๊กอิน Neovim
• สามารถติดตั้งแพ็กเกจในโครงสร้าง tree ที่เข้ากันได้กับ Neovim ด้วยแฟล็ก --nvim

Nix

• หากปลั๊กอิน Neovim มีอยู่ในรูปแบบแพ็กเกจ Luarocks ก็สามารถนำไปใช้ใน nixpkgs ได้
• lux.lock ของ Lux จะเก็บซอร์สของ dependency แต่ละตัวและค่าแฮชของ rockspec

ขั้นตอนถัดไป

• มุ่งเน้นที่การแก้บั๊กและปรับปรุงข้อความแสดงข้อผิดพลาด
• มีแผนจะเขียน rocks.nvim ใหม่บนพื้นฐานของ Lux
• หากการเขียนใหม่สำเร็จ คาดว่าจะส่งผลเชิงบวกต่อระบบนิเวศ Neovim

เอกสาร

• มีบทแนะนำและคู่มือให้ในเว็บไซต์เอกสารของ Lux
• สามารถถามคำถามและแก้ปัญหาได้ผ่าน GitHub Discussions และ issue tracker

ไลเซนส์

• Lux เผยแพร่ภายใต้ไลเซนส์ MIT
• โลโก้ Lux เผยแพร่ภายใต้ไลเซนส์ CC BY-NC-SA 4.0

[GN⁺]

ความคิดเห็นบน Hacker News

• สภาพแวดล้อมรันไทม์ของภาษาสคริปต์เป็นจุดอ่อน โดยส่วนตัวไม่ได้ใช้ Neovim แต่ก็รู้สึกว่ามันจะช่วยเร่งการพัฒนาของ Lua ได้ Bryan Cantrill เคยเรียก Javascript ว่า "LISP ที่สวมเสื้อผ้าของ C" ส่วน Lua ให้ความรู้สึกตรงกันข้าม และนั่นคือเหตุผลที่ชอบ Lua (หมายเหตุ: ไม่เคยใช้ในงาน)
  • โปรเจ็กต์อย่าง Koreader ใช้ Lua เป็นภาษาแอปพลิเคชันหลัก ถ้าสามารถโน้มน้าวให้พวกเขาเปลี่ยนมาใช้ได้ ก็จะช่วยสร้างความมั่นใจในความสุกงอมของแนวคิดและความนิยมของมัน
• เป็นโปรเจ็กต์ที่น่าสนใจ อยากร่วมงานกันเพื่อปรับปรุงการรองรับ Lua ใน Pixi (ผ่านระบบนิเวศ conda-forge) ตอนนี้ก็แพ็กเกจ Lua และ C extension บางตัวอยู่แล้ว C extension เป็นหัวใจสำคัญของ Pixi จึงน่าจะเข้ากันได้ดี
  • pixi.sh (เอกสาร)
  • แพ็กเกจ lua ในรีจิสทรี: https://prefix.dev/channels/conda-forge/packages/lua
• ฟังดูยอดเยี่ยมมาก ใช้ Lua อยู่เยอะ แต่ luarocks มีความยึดติดกับแนวทางของตัวเองมากเกินไปจนแทบใช้งานไม่ได้ อะไรก็ตามที่เกินกว่า "ติดตั้งไลบรารีเพื่อรันโดยตรงบนระบบโลคัล" หรืออยู่รอบ ๆ ขอบเขตนั้น แทบเริ่มต้นไม่ได้เลย มีสภาพแวดล้อมสคริปต์ในตัวที่ทำงานร่วมกับแพ็กเกจ Lua และอยากแพ็กสคริปต์ที่จะใช้ตรงนั้นพร้อม dependencies ด้วยหรือ? ยอมแพ้ได้เลย
  • ไม่แน่ใจว่านี่จะดีกว่าสำหรับกรณีใช้งานนี้หรือไม่ แต่ถึงอย่างนั้น luarocks ก็ยังใช้งานยากและน่าหงุดหงิด
• โดยส่วนตัวมีความเห็นต่อผู้จัดการแพ็กเกจเฉพาะภาษาโดยรวม รู้สึกว่ามันไม่ใช่ทิศทางที่ถูกต้อง คิดว่าวิธีแบบ nix ดีกว่ามาก
• ตัวจัดการแพ็กเกจของ Lua ที่พึ่งพา Rust
• ดีมาก! Lua ต้องการอะไรแบบนี้มานานเพื่อให้การสร้างแพ็กเกจทำได้ง่ายขึ้น
• ดีเลย กำลังอยากได้วิธีที่ทำซ้ำได้ในการติดตั้งแพ็กเกจ Lua บนอุปกรณ์หลายเครื่อง
• ทำไมถึงไม่ใช้ Lua สำหรับคอนฟิกแทน TOML? ถ้าจำไม่ผิด Lua เดิมทีเป็นภาษา data schema อยู่แล้ว จึงน่าจะเหมาะ
• ขอบคุณที่ให้ความสำคัญกับระบบนิเวศของ Neovim ในระดับชั้นหนึ่ง ตอนพัฒนาปลั๊กอินเคยคิดถึงความสะดวกในการใช้ไลบรารีภายนอกอย่าง Rust และ Typescript