Show HN: Lux - Lua向けの高機能なLuaパッケージマネージャー

 (mrcjkb.dev)
2 ポイント 投稿者 GN⁺ 2025-04-09 | 1件のコメント | WhatsAppで共有
  • Luxは、Luaコードの生成・保守・配布をシンプルなCLIにまとめた新しいパッケージマネージャーで、cargoのような馴染みある開発フローをLuaエコシステムにもたらすことを目指すツール
  • 1年少々の開発を経て、日常作業で十分使える状態に到達したが、MSVCサポートやエラーメッセージ、エッジケースの補強は1.0リリース前の課題として残っている
  • lux.tomlベースのプロジェクトモデル、自動rockspec生成、ロックファイル、並列ビルド、Luaヘッダーのインストール、フォーマット・lint・テスト実行をひとつの流れに統合する
  • Luarocksエコシステムとの互換性を維持しつつ、古い互換性の負債やシステムごとの予測不能さ、遅いインストール・同期体験を減らすことに重点を置いている
  • Neovimプラグイン配布とNix統合が主な用途であり、rocks.nvimをLuarocksではなくLuxベースに書き直す作業が次の段階に含まれている

Luxが提供するLuaパッケージ管理フロー

  • Luxは、Luaコードの生成・保守・配布のための新しいパッケージマネージャー
  • CLIはRustのcargoのような、よく知られたパッケージマネージャーに着想を得ている
  • 現在は「日常作業で十分使える」水準に達している
    • MSVCサポート、エラーメッセージ、エッジケースの補強はまだ残っている
    • これらの修正は1.0リリース計画に含まれている

プロジェクトモデルと開発ツールの統合

  • システム間の移植性を支援し、並列ビルドと並列インストールが可能
  • LuaヘッダーのインストールはLuxが処理する
    • 対応対象はLua 5.1、5.2、5.3、5.4、luajit
    • パッケージ作成者は互換性のあるLuaバージョンだけを指定すればよい
  • lux-lib crateは完全に埋め込み可能で、Lua APIを公開するようにビルドすることもできる
  • lux.tomlファイルを中心としたプロジェクト概念を提供する
    • lux.tomlからrockspecを自動生成する
    • リポジトリ内で複数のrockspecファイルを直接管理する負担を減らせる
  • ロックファイルは再現可能なビルドと開発環境を目的としている
    • ソースハッシュとrockspecハッシュを保存する
    • これらのハッシュは、LuxをNixと統合しやすくするために使える
  • コードフォーマットとlintもCLIに含まれている
  • bustedベースのテスト実行を標準でサポートする
    • NeovimをLuaインタプリタとして使える
    • クリーンな環境を構成する

Luarocksとの違い

  • Luarocksは守備範囲が広いが、およそ20年分の互換性の負債のため、現代的なLua開発に合わせにくいという問題がある
  • Luxは新たな出発を目指し、TOMLを主マニフェスト形式として使う
    • CLIで依存関係の追加、削除、固定、更新ができる
    • lux.tomlがあるプロジェクトディレクトリでbuildのようなコマンドを実行すると、プロジェクトをビルドしてプロジェクトローカルツリーにインストールする
    • ビルド過程でプロジェクト依存関係のロックファイルを作成し、互換システム上で同じ依存関係を再現できる
  • SemVerの扱いを推奨する方法も異なる
    • Luarocksはパッチバージョンの後ろに任意のバージョンを許可する
    • たとえば1.0.1.0.0.0.2はLuarocksでは有効だが、有用な意味はないとみなしている
    • Luxもこれをパースするが、パッチバージョン以降の値はプレリリース版として扱う
  • 並列ビルドはNix storeに着想を得ている
    • Luxはインストールディレクトリをハッシュ化してパッケージ衝突を防ぎ、ファイルシステム破損のリスクなしに並列ビルドを可能にする
    • 関連する詳細はLuxのパッケージ衝突ガイドにある

Neovimエコシステムでの利用

  • rocks.nvimとlazy.nvimによるLuarocksサポート以降、LuarocksはNeovimプラグイン配布手段として人気を集めている
  • ただし既存のLuarocks利用には、完全な移植性が不足し、システムごとに結果を予測しにくいという制約がある
  • LuarocksはLuaで書かれているため、多数のパッケージインストールやrocks.nvimプラグイン同期が非常に遅かった
  • Luxの利用は非破壊的で、現在のNeovimプラグインのGitベース配布方式を妨げない
  • --nvimフラグを使うと、パッケージをNeovimの:h packagesと互換性のあるツリー構造にインストールする

Nix統合のためのロックファイル

  • NeovimプラグインがLuarocksパッケージとして存在する場合、nixpkgsはそれを基準ソースとして使う
    • 適切なパッケージマネージャーでは、依存関係宣言の責任がパッケージ作成者にあるため
  • Luarocksのロックファイル対応は基本的で、ソースハッシュを含まない
  • LuarocksとLuxはいずれもluarocks.loaderを通じて衝突する依存関係をサポートする
  • nixpkgsでは、同じ依存関係の複数バージョンをパッケージセットに合理的に追加するのが難しい
  • Luxのlux.lockは、各依存関係のソースハッシュとrockspecハッシュを保存する
    • ソースURLがGitリポジトリなら、LuxはNAR hashを保存する
    • lux.lockはCargo.lockのように、すべての依存関係を含むfixed-output derivationを作るために使える

次の段階とドキュメント

  • 現在の優先事項はバグ修正とエラーメッセージ改善
  • rocks.nvimはLuarocksの代わりにLuxを内部利用するよう書き直される予定
    • この書き直しは、rocks.nvimの速度を他のプラグインマネージャー並みに引き上げることを目標とする
    • 成功すれば、Luxを他の場所にも埋め込めることを示す事例になる
    • 例として、過去にLuarocks関連の問題があったlazy.nvimが挙げられている
  • 初期ユーザーはドキュメントサイトでチュートリアルやガイドを見られる
  • 質問や課題はGitHub discussionsまたはissue trackerで受け付けている
  • LuxはLGPLv3.0+ライセンスで、Luxロゴは© 2025 Kai JakobiのCC BY-NC-SA 4.0ライセンス

関連記事

1件のコメント

 
GN⁺ 2025-04-09
Hacker News のコメント

  • スクリプト言語のアキレス腱は実行環境です。個人的に Neovim は使っていませんが、Neovim の採用が Lua 側でこの領域の発展を後押しするのではないかと思っていました
    Bryan Cantrill は JavaScript を「C の服を着た LISP」と呼びましたが、ある意味では Lua はその逆のように感じられて、そこが好きです。ただし、仕事で使う必要に迫られたことはありません

    • JavaScript が C の服を着た Lisp だという根拠が何なのか分かりません。Lua が Lisp と何の関係があるのかも分かりませんし、Lisp 構文はまったくありません

  • Koreader[1] のようなプロジェクトは、Lua を主要なアプリケーション言語として使っていると認識しています。そうしたプロジェクトの一つに移行を説得できれば、このアイデアの成熟度と人気について、ある程度の確信を与えられそうです
    [1]: https://github.com/koreader/koreader

    • 良い提案です。Lux が成熟するにはもう少し時間が必要でしょうが、koreader のような大規模マルチプラットフォームプロジェクトをビルドするのは、確かに良い目標になり得ます

  • 本当に良さそうです。Lua はよく使っていますが、luarocks は方向性が強すぎて、必要な用途にはほとんど役に立ちませんでした
    「ローカルシステムで直接実行するライブラリをインストールする」以上のことから少しでも外れると、最初から行き詰まります。Lua パッケージを使う組み込みスクリプティング環境があり、依存関係込みでスクリプトをまとめて配布したいなら、諦めるしかありませんでした
    このツールがその用途により良いのかは分かりませんが、そうでないとしても luarocks は良く言っても無骨で、使っていて苛立ちます

    • Lua コミュニティは C ライブラリへの依存度がものすごく高く、ほぼすべての luarocks パッケージがライブラリをビルドしようとするため、Windows では実質的に役に立たなくなります

  • 興味深いプロジェクトです。Pixi で conda-forge エコシステムを通じて、より良い Lua サポートを作るために一緒に作業したいです
    すでに lua といくつかの C 拡張をパッケージングしています。C 拡張は Pixi の中核領域なので、相性が良いと思います
    pixi.sh のドキュメントとレジストリの lua パッケージ: https://prefix.dev/channels/conda-forge/packages/lua

    • 良いアイデアだと思います。リポジトリに issue を立てておいたので、そこで気軽に ping してください

  • ここや関連サイトで見当たらなかったので質問します。package.path と package.cpath にネイティブに統合されるのか、brew(1) のような非標準だが広く使われているインストールを検出するのか、GitHub の :user/:repository 方式でインストールできるのかが気になります
    プロジェクトは素晴らしく、よくできていると思います

    • lx run と lx lua コマンドは PATH、LUA_PATH、LUA_CPATH を設定します。そして、その環境変数を設定するための lx path コマンドもあります
      Lua インストールの検出は基本的に pkg-config を使い、見つからなければ lua_src と luajit_src クレートで Lua のインストールを試みます。将来的には vcpkg のような他のツールのサポートも追加できます
      GitHub の :user/:repository インストールはまだできません。lux.toml/依存関係の指定に追加する計画はありますが、その方式の rockspec を luarocks.org に公開することはおそらく許可しないつもりです。luarocks でビルドできないパッケージを人々が投稿する原因になりたくないからです

  • C に組み込まれるよう設計され、C ライブラリに大きく依存する言語のためのパッケージマネージャが Rust で書かれ、Lua 自体は C プログラムの設定言語として作られたのに、設定は TOML で行うということですか
    遠慮します。Luarocks には限界があり、おそらく書き直す必要はあるでしょうが、エコシステムに合った言語を使い、Lua エコシステムの文化に従うべきです。Rust と Cargo は Lua とは正反対にあります

    • Lua は進化してきており、当初作られた用途よりもはるかに多くの場所で使われています

  • 個人的には、こうした言語別パッケージマネージャにはもううんざりです。正しい方向だとは感じられず、nix のようなアプローチの方がずっと良さそうに見えます

    • Lux の動機の一つは、nixpkgs の Lua と Neovim エコシステムを改善することです

  • Rust に依存する Lua 用パッケージマネージャとは

    • 特に問題はなさそうです。ほとんどのパッケージマネージャはバイナリ専用パッケージのインストールをサポートしています
    • 思ったよりうまく動いて驚くかもしれません
    • しかも TOML まで使います

  • 気に入りました。かなり前から、複数のマシンで再現可能な Lua パッケージインストール方法が欲しいと思っていました

    • 複数のマシンで再現可能な Lua パッケージインストール状態は作りましたが、Lua は主に二つの方法で使っています
      一つは「素の」形で内部 VM にリンクし、プロジェクトビルドの一部として .lua コードベースを管理する方法です。もう一つはシステムツールとして使い、luarocks --local や luaenv のようなツールを適宜使って Makefile/CMakeLists.txt に組み込み、配布用バンドルには luastatic を少し混ぜる方法です
      正直なところ、これは Python や同梱され得る他のスクリプト言語と大きくは変わりません。ただし、システムが提供する /bin/script_language と、より大きなプロジェクト内の開発ツール/スクリプティングエンジン、あるいはローカル作業台向けツールとして使う言語は、常に区別する必要があります
      Lua が本当に好きな理由の一つは、ライブラリをパッケージングし、バイトコードをリンクし、バンドルを包んで対象 OS のユーザーにワンクリックインストールの形で提供するのが、かなり簡単で楽しいからです。もちろん、ある程度は手を動かす必要があります

  • 素晴らしくはありますが、Lua の設計方針とは逆に進んでいる感が強いです。Lua はシンプルな組み込み用言語として設計されており、そこでの「パッケージ管理」とは zip をいくつかダウンロードして展開することであり、「バージョン管理」とは 5.1 互換で使うか 5.4 互換で使うかを選ぶ程度に近いものです