Show HN: Lux - Lua के लिए उन्नत Lua पैकेज मैनेजर

 (mrcjkb.dev)
2 पॉइंट द्वारा GN⁺ 2025-04-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Lux एक नया पैकेज मैनेजर है जो Lua code के निर्माण, रखरखाव और deployment को एक सरल CLI में जोड़ता है; यह cargo जैसे परिचित development flow को Lua ecosystem में लाने का tool है
  • एक साल से थोड़ा अधिक development के बाद यह रोज़मर्रा के कामों के लिए बहुत उपयोगी स्थिति में पहुंच गया है, लेकिन MSVC support, error messages और edge cases में सुधार 1.0 release से पहले बाकी हैं
  • यह lux.toml-आधारित project model, automatic rockspec generation, lockfile, parallel builds, Lua header installation, और formatting·linting·test execution को एक flow में integrate करता है
  • Luarocks ecosystem के साथ compatibility बनाए रखते हुए, यह पुराने compatibility burden, system-specific unpredictability, और धीमे install·sync experience को कम करने पर केंद्रित है
  • Neovim plugin distribution और Nix integration इसके मुख्य use cases हैं, और rocks.nvim को Luarocks के बजाय Lux-आधारित रूप में rewrite करना अगले चरणों में शामिल है

Lux द्वारा दिया जाने वाला Lua package management flow

  • Lux Lua code के creation, maintenance और distribution के लिए नया package manager है
  • CLI, Rust के cargo जैसे जाने-पहचाने package managers से प्रेरित है
  • फिलहाल यह “रोज़मर्रा के कामों के लिए बहुत उपयोगी” स्तर तक पहुंच गया है
    • MSVC support, error messages और edge cases में सुधार अभी बाकी है
    • ये fixes 1.0 release plan में शामिल हैं

Project model और development tools integration

  • यह systems के बीच portability support करता है, और parallel build व parallel installation संभव हैं
  • Lua headers की installation Lux संभालता है
    • supported targets Lua 5.1, 5.2, 5.3, 5.4, luajit हैं
    • package authors को केवल compatible Lua versions specify करने होते हैं
  • lux-lib crate पूरी तरह embeddable है, और इसे Lua API expose करने के लिए भी build किया जा सकता है
  • यह lux.toml file पर केंद्रित project concept देता है
    • lux.toml से rockspec अपने-आप generate होता है
    • repository में कई rockspec files को सीधे manage करने का बोझ कम होता है
  • lockfile का लक्ष्य reproducible builds और development environments हैं
    • यह source hash और rockspec hash store करता है
    • इन hashes का उपयोग Lux को Nix के साथ integrate करना आसान बनाने में किया जा सकता है
  • Code formatting और linting भी CLI में शामिल हैं
    • lx fmt stylua का उपयोग करता है
    • lx check luacheck का उपयोग करता है
  • busted based test execution को default support है
    • Neovim को Lua interpreter के रूप में इस्तेमाल किया जा सकता है
    • यह clean environment configure करता है

Luarocks से अंतर

  • Luarocks का scope व्यापक है, लेकिन करीब 20 साल के compatibility burden के कारण इसे modern Lua development के अनुरूप बनाना मुश्किल है
  • Lux fresh start का लक्ष्य रखता है, और TOML को main manifest format के रूप में उपयोग करता है
    • CLI से dependencies add, remove, pin और update की जा सकती हैं
    • lux.toml वाले project directory में build जैसे commands project को build करते हैं और project-local tree में install करते हैं
    • build process के दौरान project dependencies का lockfile बनता है, ताकि compatible systems पर वही dependencies reproduce की जा सकें
  • SemVer के उपयोग को encourage करने का तरीका भी अलग है
    • Luarocks patch version के बाद arbitrary versions allow करता है
    • उदाहरण के लिए 1.0.1.0.0.0.2 Luarocks में valid है, लेकिन इसे useful meaning वाला नहीं माना जाता
    • Lux भी इसे parse करता है, लेकिन patch version के बाद की values को prerelease version के रूप में treat करता है
  • Parallel build Nix store से प्रेरित है
    • Lux install directory को hash करता है ताकि package conflicts रुकें, और filesystem corruption के जोखिम के बिना parallel builds संभव हों
    • संबंधित details Lux की package conflict guide में हैं

Neovim ecosystem में उपयोग

  • rocks.nvim और lazy.nvim के Luarocks support के बाद, Luarocks Neovim plugin distribution method के रूप में लोकप्रिय हो रहा है
  • हालांकि मौजूदा Luarocks use में पूरी portability की कमी है, और system के हिसाब से results predict करना कठिन है
  • Luarocks Lua में लिखा होने के कारण कई packages install करना और rocks.nvim plugins sync करना बहुत धीमा था
  • Lux का उपयोग non-destructive है, और Neovim plugins की मौजूदा Git-based distribution method में बाधा नहीं डालता
  • --nvim flag का उपयोग करने पर packages को Neovim के :h packages के compatible tree structure में install किया जाता है

Nix integration के लिए lockfile

  • जब Neovim plugin Luarocks package के रूप में मौजूद होता है, तो nixpkgs उसे reference source के रूप में उपयोग करता है
    • क्योंकि उपयुक्त package manager में dependency declaration की जिम्मेदारी package author की होती है
  • Luarocks का lockfile support basic है और इसमें source hash शामिल नहीं होता
  • Luarocks और Lux दोनों luarocks.loader के जरिए conflicting dependencies support करते हैं
  • nixpkgs के लिए एक ही dependency के कई versions को package set में समझदारी से add करना कठिन है
  • Lux का lux.lock हर dependency का source hash और rockspec hash store करता है
    • अगर source URL Git repository है, तो Lux NAR hash store करता है
    • lux.lock का उपयोग Cargo.lock की तरह सभी dependencies सहित fixed-output derivation बनाने में किया जा सकता है

अगले कदम और documentation

  • मौजूदा priority bug fixes और error messages में सुधार है
  • rocks.nvim को Luarocks के बजाय अंदरूनी तौर पर Lux इस्तेमाल करने के लिए rewrite किया जाएगा
    • इस rewrite का लक्ष्य rocks.nvim की speed को दूसरे plugin managers के स्तर तक लाना है
    • सफल होने पर यह दिखाने वाला case होगा कि Lux को अन्य जगहों पर भी embed किया जा सकता है
    • उदाहरण के तौर पर lazy.nvim का उल्लेख है, जिसमें पहले Luarocks-related issues थे
  • शुरुआती users documentation site पर tutorials और guides देख सकते हैं
  • सवाल या issues GitHub discussions या issue tracker पर भेजे जा सकते हैं
  • Lux LGPLv3.0+ license के तहत है, और Lux logo © 2025 Kai Jakobi के CC BY-NC-SA 4.0 license के तहत है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-04-09
Hacker News टिप्पणियां

  • scripting languages की Achilles heel execution environment होती है। मैं व्यक्तिगत रूप से Neovim इस्तेमाल नहीं करता, लेकिन लगा था कि Neovim अपनाए जाने से Lua में इस क्षेत्र का विकास आगे बढ़ेगा
    Bryan Cantrill ने JavaScript को “C के कपड़े पहना LISP” कहा था; कुछ मायनों में Lua उसका उल्टा लगता है, और इसलिए मुझे पसंद है। हालांकि काम में इसे इस्तेमाल करना कभी नहीं पड़ा

    • JavaScript को C के कपड़े पहना Lisp कहने का आधार क्या है, समझ नहीं आता। Lua का Lisp से क्या संबंध है, यह भी नहीं समझता, और इसमें Lisp syntax बिल्कुल नहीं है

  • मेरी जानकारी में Koreader[1] जैसे प्रोजेक्ट Lua को मुख्य application language के रूप में इस्तेमाल करते हैं। अगर ऐसे किसी प्रोजेक्ट को migrate करने के लिए राज़ी किया जा सके, तो इस idea की maturity और popularity पर कुछ भरोसा मिल सकता है
    [1]: https://github.com/koreader/koreader

    • अच्छा सुझाव है। Lux को mature होने में थोड़ा समय लगेगा, लेकिन koreader जैसे बड़े multiplatform project को build करना निश्चित रूप से एक अच्छा लक्ष्य हो सकता है

  • वाकई अच्छा लग रहा है। मैं Lua काफी इस्तेमाल करता हूं, और luarocks इतना ज्यादा opinionated है कि जिन कामों के लिए मुझे चाहिए था, उनमें लगभग बेकार साबित हुआ
    “local system पर सीधे चलाने के लिए libraries install करना” से थोड़ा भी आगे जाते ही शुरुआत में ही अटक जाता है। अगर आपके पास Lua packages इस्तेमाल करने वाला embedded scripting environment है और आप dependencies के साथ scripts को bundle करके distribute करना चाहते हैं, तो हार माननी पड़ती थी
    नहीं पता कि यह tool उस use case के लिए बेहतर है या नहीं, लेकिन भले न हो, luarocks best case में भी rough है और इस्तेमाल करने में चिढ़ाता है

    • Lua community की C libraries पर dependency बहुत ज्यादा है, और लगभग हर luarocks package library build करने की कोशिश करता है, जिससे Windows पर यह practically बेकार हो जाता है

  • दिलचस्प project है। Pixi में conda-forge ecosystem के जरिए बेहतर Lua support बनाने पर साथ काम करना चाहूंगा
    हम पहले से lua और कुछ C extensions package कर रहे हैं। C extensions Pixi का core area हैं, इसलिए यह अच्छा fit हो सकता है
    pixi.sh docs और registry में lua package: https://prefix.dev/channels/conda-forge/packages/lua

    • अच्छा idea लगता है। repository में an issue खोल दिया है, वहां आराम से ping कर दें

  • यहां या related site पर नहीं दिखा, इसलिए पूछ रहा हूं: क्या यह package.path और package.cpath के साथ natively integrate होता है, क्या brew(1) जैसे non-standard लेकिन widely used installations detect करता है, और क्या GitHub :user/:repository तरीके से install किया जा सकता है?
    project शानदार और अच्छी तरह बनाया हुआ लगता है

    • lx run और lx lua commands PATH, LUA_PATH, LUA_CPATH set करते हैं। और उन environment variables को set करने के लिए lx path command भी है
      Lua installation detection default रूप से pkg-config इस्तेमाल करता है, और अगर नहीं मिलता तो lua_src और luajit_src crates से Lua install करने की कोशिश करता है। बाद में vcpkg जैसे दूसरे tools का support भी जोड़ा जा सकता है
      GitHub :user/:repository installation अभी नहीं है। lux.toml/dependency spec में जोड़ने की योजना है, लेकिन उस तरीके के rockspec को luarocks.org पर publish करने की शायद अनुमति नहीं देंगे। क्योंकि मैं ऐसा कारण नहीं बनना चाहता कि लोग ऐसे packages upload करें जिन्हें luarocks से build नहीं किया जा सकता

  • C में embed होने के लिए designed और C libraries पर बहुत निर्भर language के लिए package manager Rust में लिखा गया है, और Lua खुद C programs की configuration language के रूप में बना था, लेकिन configuration TOML में होगी?
    नहीं चाहिए। Luarocks की सीमाएं हैं और शायद इसे फिर से लिखना चाहिए, लेकिन ecosystem के अनुकूल language इस्तेमाल करनी चाहिए और Lua ecosystem की culture का पालन करना चाहिए। Rust और Cargo, Lua के ठीक opposite side पर हैं

    • Lua evolve हुआ है और अपनी शुरुआती use case से कहीं ज्यादा जगहों पर इस्तेमाल हो रहा है

  • व्यक्तिगत रूप से मैं ऐसे language-specific package managers से बहुत ऊब चुका हूं। यह सही दिशा नहीं लगती, और nix जैसा approach कहीं बेहतर लगता है

    • Lux की motivations में से एक nixpkgs के Lua और Neovim ecosystem को improve करना है

  • Rust पर depend करने वाला Lua package manager

    • कोई खास समस्या नहीं लगती। ज्यादातर package managers binary-only package installation support करते हैं
    • आप हैरान हो सकते हैं कि यह उम्मीद से बेहतर काम करता है
    • और TOML भी इस्तेमाल करता है

  • पसंद आया। काफी समय से कई machines पर reproducible Lua package installations का तरीका चाहता था

    • मैंने कई machines पर reproducible Lua package installation state बनाई है, लेकिन Lua को मुख्यतः दो तरीकों से इस्तेमाल करता हूं
      एक “raw” रूप में, internal VM में link करके project build के हिस्से के रूप में .lua codebase manage करना; और दूसरा system tool के रूप में इस्तेमाल करते हुए luarocks --local, luaenv जैसे tools को ठीक से Makefile/CMakeLists.txt में डालना, और distribution bundle के लिए luastatic थोड़ा मिलाना
      सच कहूं तो यह Python या साथ में ship की जा सकने वाली दूसरी scripting languages से बहुत अलग नहीं है। बस system-provided /bin/script_language और किसी बड़े project के अंदर development tool/scripting engine या local workbench tool के रूप में इस्तेमाल की जाने वाली language को हमेशा अलग रखना चाहिए
      Lua को सचमुच पसंद करने की एक वजह यह है कि libraries को package करना, bytecode link करना, और bundle wrap करके target operating system users को one-click install के रूप में देना काफी आसान और मजेदार है। बेशक, कुछ हाथ-पैर तो चलाने पड़ते हैं

  • बढ़िया तो है, लेकिन Lua की design direction के उलट जाने का एहसास काफी मजबूत है। Lua को एक सरल embedding language के रूप में design किया गया था, और यहां “package management” कुछ zip files download करके extract करने जैसा है, जबकि “version management” लगभग यह चुनने जैसा है कि 5.1-compatible इस्तेमाल करना है या 5.4-compatible