Show HN: Lux - manajer paket Lua tingkat lanjut untuk Lua

 (mrcjkb.dev)
2 poin oleh GN⁺ 2025-04-09 | 1 komentar | Bagikan ke WhatsApp
  • Lux adalah manajer paket baru yang menyatukan pembuatan, pemeliharaan, dan distribusi kode Lua dalam CLI yang sederhana, dengan tujuan membawa alur kerja pengembangan yang familier seperti cargo ke ekosistem Lua
  • Setelah dikembangkan selama sedikit lebih dari setahun, proyek ini telah mencapai kondisi sangat layak dipakai untuk pekerjaan sehari-hari, meski dukungan MSVC, pesan kesalahan, dan penanganan edge case masih menjadi pekerjaan sebelum rilis 1.0
  • Model proyek berbasis lux.toml, pembuatan rockspec otomatis, lockfile, build paralel, instalasi header Lua, serta pemformatan, linting, dan pengujian terintegrasi dalam satu alur
  • Sambil tetap menjaga kompatibilitas dengan ekosistem Luarocks, fokusnya adalah mengurangi beban kompatibilitas lama, ketidakpastian antar-sistem, serta pengalaman instalasi dan sinkronisasi yang lambat
  • Distribusi plugin Neovim dan integrasi Nix menjadi kasus penggunaan utama, dan langkah berikutnya mencakup penulisan ulang rocks.nvim agar berbasis Lux alih-alih Luarocks

Alur manajemen paket Lua yang ditawarkan Lux

  • Lux adalah manajer paket baru untuk membuat, memelihara, dan mendistribusikan kode Lua
  • CLI-nya terinspirasi dari manajer paket yang sudah dikenal luas seperti cargo milik Rust
  • Saat ini proyek ini telah mencapai tingkat “sangat layak dipakai untuk pekerjaan sehari-hari”
    • Dukungan MSVC, pesan kesalahan, dan penanganan edge case masih belum selesai
    • Perbaikan tersebut termasuk dalam rencana rilis 1.0

Model proyek dan integrasi alat pengembangan

  • Mendukung portabilitas antar-sistem, serta memungkinkan build dan instalasi paralel
  • Lux menangani instalasi header Lua
    • Yang didukung adalah Lua 5.1, 5.2, 5.3, 5.4, dan luajit
    • Penulis paket hanya perlu menentukan versi Lua yang kompatibel
  • Crate lux-lib sepenuhnya bisa di-embed, dan juga dapat dibangun agar mengekspor API Lua
  • Menyediakan konsep proyek yang berpusat pada file lux.toml
    • Rockspec dibuat secara otomatis dari lux.toml
    • Ini mengurangi beban mengelola banyak file rockspec langsung di repositori
  • Lockfile ditujukan untuk build dan lingkungan pengembangan yang reproducible
    • Menyimpan hash sumber dan hash rockspec
    • Hash ini dapat digunakan untuk mempermudah integrasi Lux dengan Nix
  • Pemformatan dan linting kode juga sudah termasuk di dalam CLI
  • Mendukung eksekusi pengujian berbasis busted secara bawaan
    • Neovim dapat digunakan sebagai interpreter Lua
    • Menyusun lingkungan yang bersih

Perbedaan dengan Luarocks

  • Luarocks memiliki cakupan luas, tetapi sekitar 20 tahun beban kompatibilitas membuatnya sulit disesuaikan dengan pengembangan Lua modern
  • Lux menargetkan awal yang baru dan menggunakan TOML sebagai format manifest utama
    • Dependensi dapat ditambahkan, dihapus, dikunci, dan diperbarui lewat CLI
    • Di direktori proyek yang memiliki lux.toml, perintah seperti build akan membangun proyek dan menginstalnya ke tree lokal proyek
    • Selama proses build, dibuat lockfile dependensi proyek agar dependensi yang sama dapat direproduksi pada sistem yang kompatibel
  • Cara mendorong penggunaan SemVer juga berbeda
    • Luarocks mengizinkan versi arbitrer setelah versi patch
    • Misalnya 1.0.1.0.0.0.2 valid di Luarocks, tetapi dianggap tidak memiliki makna yang berguna
    • Lux juga dapat mem-parsing ini, tetapi nilai setelah versi patch diperlakukan sebagai versi prarilis
  • Build paralel terinspirasi dari Nix store
    • Lux melakukan hashing pada direktori instalasi untuk mencegah konflik paket, dan memungkinkan build paralel tanpa risiko merusak filesystem
    • Detail terkait ada di panduan konflik paket milik Lux

Penggunaan dalam ekosistem Neovim

  • Setelah dukungan Luarocks hadir di rocks.nvim dan lazy.nvim, Luarocks mulai populer sebagai cara mendistribusikan plugin Neovim
  • Namun, penggunaan Luarocks yang ada saat ini memiliki keterbatasan dalam portabilitas penuh, dan hasilnya sulit diprediksi antar-sistem
  • Karena Luarocks ditulis dalam Lua, instalasi banyak paket dan sinkronisasi plugin rocks.nvim menjadi sangat lambat
  • Penggunaan Lux bersifat non-destruktif, dan saat ini tidak mengganggu cara distribusi plugin Neovim berbasis Git
  • Dengan flag --nvim, paket diinstal ke struktur tree yang kompatibel dengan :h packages milik Neovim

Lockfile untuk integrasi Nix

  • Jika plugin Neovim tersedia sebagai paket Luarocks, maka nixpkgs menggunakannya sebagai sumber acuan
    • Ini karena pada manajer paket yang semestinya, tanggung jawab deklarasi dependensi ada pada penulis paket
  • Dukungan lockfile Luarocks bersifat dasar dan tidak menyertakan hash sumber
  • Baik Luarocks maupun Lux mendukung dependensi yang saling bentrok melalui luarocks.loader
  • Bagi nixpkgs, menambahkan banyak versi dari dependensi yang sama ke set paket secara masuk akal itu sulit
  • lux.lock milik Lux menyimpan hash sumber dan hash rockspec untuk setiap dependensi
    • Jika URL sumber adalah repositori Git, Lux akan menyimpan NAR hash
    • lux.lock dapat digunakan seperti Cargo.lock untuk membuat fixed-output derivation yang mencakup semua dependensi

Langkah berikutnya dan dokumentasi

  • Prioritas saat ini adalah perbaikan bug dan peningkatan pesan kesalahan
  • rocks.nvim direncanakan akan ditulis ulang agar secara internal menggunakan Lux alih-alih Luarocks
    • Penulisan ulang ini bertujuan meningkatkan kecepatan rocks.nvim hingga setara dengan pengelola plugin lain
    • Jika berhasil, ini akan menjadi contoh bahwa Lux dapat di-embed di tempat lain juga
    • Sebagai contoh disebutkan lazy.nvim, yang pernah memiliki masalah terkait Luarocks di masa lalu
  • Pengguna awal dapat melihat tutorial dan panduan di situs dokumentasi
  • Pertanyaan atau isu dapat disampaikan melalui GitHub discussions atau issue tracker
  • Lux berlisensi LGPLv3.0+, dan logo Lux berlisensi © 2025 Kai Jakobi CC BY-NC-SA 4.0

Bacaan terkait

1 komentar

 
GN⁺ 2025-04-09
Komentar Hacker News

  • Kelemahan terbesar bahasa scripting adalah lingkungan eksekusi. Secara pribadi saya tidak memakai Neovim, tetapi saya merasa adopsi Neovim akan mendorong kemajuan area ini di sisi Lua
    Bryan Cantrill pernah menyebut JavaScript sebagai “LISP berbaju C”; dalam beberapa hal Lua terasa seperti kebalikannya, dan karena itu saya menyukainya. Hanya saja, saya belum pernah harus memakainya untuk pekerjaan

    • Saya tidak tahu atas dasar apa JavaScript disebut Lisp berbaju C. Saya juga tidak tahu apa hubungan Lua dengan Lisp, dan sama sekali tidak ada sintaks Lisp

  • Sejauh yang saya tahu, proyek seperti Koreader[1] memakai Lua sebagai bahasa aplikasi utama. Jika bisa meyakinkan salah satu proyek seperti itu untuk beralih, rasanya itu bisa memberi keyakinan tertentu soal kematangan dan popularitas ide ini
    [1]: https://github.com/koreader/koreader

    • Saran yang bagus. Lux mungkin masih butuh waktu untuk matang, tetapi membangun proyek multiplatform besar seperti koreader jelas bisa menjadi target yang bagus

  • Kelihatannya sangat bagus. Saya banyak memakai Lua, dan luarocks punya arah yang terlalu kaku sehingga hampir tidak berguna untuk kebutuhan saya
    Begitu sedikit saja keluar dari “menginstal library untuk dijalankan langsung di sistem lokal”, semuanya langsung buntu sejak awal. Kalau punya lingkungan scripting tertanam yang memakai paket Lua dan ingin membundel skrip bersama dependensinya untuk didistribusikan, ya harus menyerah
    Saya tidak tahu apakah alat ini lebih baik untuk kebutuhan itu, tetapi kalaupun tidak, luarocks paling banter tetap kikuk dan menyebalkan untuk dipakai

    • Komunitas Lua sangat bergantung pada library C, dan hampir semua paket luarocks mencoba membangun library, sehingga di Windows praktis menjadi tidak berguna

  • Proyek yang menarik. Saya ingin bekerja sama untuk membuat dukungan Lua yang lebih baik di Pixi melalui ekosistem conda-forge
    Kami sudah memaketkan lua dan beberapa ekstensi C. Ekstensi C adalah area inti Pixi, jadi menurut saya ini bisa cocok
    Dokumentasi pixi.sh dan paket lua di registry: https://prefix.dev/channels/conda-forge/packages/lua

    • Sepertinya ide bagus. Saya sudah membuka an issue di repositori, jadi silakan ping di sana

  • Karena saya tidak melihatnya di sini atau di situs terkait, saya ingin bertanya: apakah ini terintegrasi secara native dengan package.path dan package.cpath, apakah mendeteksi instalasi nonstandar tetapi banyak dipakai seperti brew(1), dan apakah bisa menginstal dengan gaya GitHub :user/:repository?
    Proyeknya terlihat keren dan dibuat dengan baik

    • Perintah lx run dan lx lua mengatur PATH, LUA_PATH, LUA_CPATH. Ada juga perintah lx path untuk mengatur variabel lingkungan tersebut
      Deteksi instalasi Lua pada dasarnya memakai pkg-config, dan jika tidak ditemukan, ia mencoba menginstal Lua lewat crate lua_src dan luajit_src. Ke depannya dukungan untuk alat lain seperti vcpkg juga bisa ditambahkan
      Instalasi GitHub :user/:repository belum bisa. Ada rencana menambahkannya ke lux.toml/spesifikasi dependensi, tetapi kemungkinan tidak akan mengizinkan rockspec dengan gaya itu dipublikasikan ke luarocks.org. Sebab saya tidak ingin menjadi penyebab orang mengunggah paket yang tidak bisa dibangun dengan luarocks

  • Jadi manajer paket untuk bahasa yang dirancang agar ditanamkan di C dan sangat bergantung pada library C ini ditulis dengan Rust, sementara Lua sendiri dibuat sebagai bahasa konfigurasi untuk program C, tetapi konfigurasinya memakai TOML?
    Tidak, terima kasih. Luarocks memang punya keterbatasan dan mungkin perlu ditulis ulang, tetapi harus memakai bahasa yang sesuai dengan ekosistemnya dan mengikuti budaya ekosistem Lua. Rust dan Cargo berada tepat di sisi berlawanan dari Lua

    • Lua sudah berkembang, dan sekarang dipakai di jauh lebih banyak tempat daripada tujuan awal pembuatannya

  • Secara pribadi saya sudah sangat jenuh dengan manajer paket per bahasa seperti ini. Rasanya bukan arah yang benar; pendekatan seperti nix terlihat jauh lebih baik

    • Salah satu motivasi Lux adalah memperbaiki ekosistem Lua dan Neovim di nixpkgs

  • Manajer paket untuk Lua yang bergantung pada Rust, ya

    • Sepertinya bukan masalah besar. Kebanyakan manajer paket mendukung instalasi paket berbasis biner saja
    • Anda mungkin akan terkejut karena ternyata bekerja lebih baik dari dugaan
    • Dan juga memakai TOML

  • Saya suka. Sudah cukup lama saya ingin punya cara untuk menginstal paket Lua secara reproducible di beberapa mesin

    • Saya pernah membuat status instalasi paket Lua yang reproducible di beberapa mesin, tetapi saya terutama memakai Lua dengan dua cara
      Yang pertama adalah bentuk “mentah”, ditautkan ke VM internal dan mengelola basis kode .lua sebagai bagian dari build proyek; yang kedua adalah memakainya sebagai alat sistem sambil memasukkan tool seperti luarocks --local dan luaenv seperlunya ke Makefile/CMakeLists.txt, lalu sedikit memadukan luastatic untuk bundel distribusi
      Sejujurnya ini tidak terlalu berbeda dari Python atau bahasa scripting lain yang bisa ikut dibundel. Hanya saja kita harus selalu membedakan antara /bin/script_language yang disediakan sistem dan bahasa yang dipakai sebagai alat pengembangan/mesin scripting di dalam proyek yang lebih besar atau sebagai alat untuk workstation lokal
      Salah satu alasan saya sangat menyukai Lua adalah karena memaketkan library, menautkan bytecode, membungkus bundel, lalu menyediakannya kepada pengguna sistem operasi target dalam bentuk instalasi sekali klik itu cukup mudah dan menyenangkan. Tentu tetap perlu sedikit kerja manual

  • Ini bagus, tetapi terasa kuat bergerak berlawanan dengan arah desain Lua. Lua dirancang sebagai bahasa tertanam yang sederhana, dan di sini “manajemen paket” kurang lebih berarti mengunduh lalu mengekstrak beberapa zip, sedangkan “manajemen versi” lebih seperti memilih apakah akan memakai kompatibilitas 5.1 atau kompatibilitas 5.4