Show HN: Lux - Lua için gelişmiş bir Lua paket yöneticisi

 (mrcjkb.dev)
2 puan yazan GN⁺ 2025-04-09 | 1 yorum | WhatsApp'ta paylaş
  • Lux, Lua kodunun oluşturulmasını, bakımını ve dağıtımını basit bir CLI altında toplayan yeni bir paket yöneticisi; cargo benzeri tanıdık geliştirme akışlarını Lua ekosistemine getirmeyi hedefliyor
  • Bir yıldan biraz uzun süren geliştirme sonrasında günlük işler için oldukça kullanılabilir bir duruma ulaştı; ancak MSVC desteği, hata mesajları ve uç durumların iyileştirilmesi 1.0 sürümü öncesindeki işler arasında kalıyor
  • lux.toml tabanlı proje modeli, otomatik rockspec üretimi, lockfile, paralel derleme, Lua header kurulumu ve biçimlendirme/lint/test çalıştırmayı tek bir akışta birleştiriyor
  • Luarocks ekosistemiyle uyumluluğu korurken, eski uyumluluk yükünü, sisteme göre değişen öngörülemezliği ve yavaş kurulum/senkronizasyon deneyimini azaltmaya odaklanıyor
  • Neovim eklentilerinin dağıtımı ve Nix entegrasyonu başlıca kullanım alanları; rocks.nvimin Luarocks yerine Lux tabanlı olarak yeniden yazılması sonraki adımlar arasında yer alıyor

Lux’un sunduğu Lua paket yönetimi akışı

  • Lux, Lua kodunun oluşturulması, bakımı ve dağıtımı için yeni bir paket yöneticisi
  • CLI, Rust’ın cargo gibi iyi bilinen paket yöneticilerinden ilham alıyor
  • Şu anda “günlük işler için oldukça kullanılabilir” seviyeye ulaşmış durumda
    • MSVC desteği, hata mesajları ve uç durum iyileştirmeleri hâlâ tamamlanmayı bekliyor
    • Bu düzeltmeler 1.0 sürümü planına dahil

Proje modeli ve geliştirme araçları entegrasyonu

  • Sistemler arasında taşınabilirliği destekler; paralel derleme ve paralel kurulum yapabilir
  • Lua header kurulumunu Lux üstlenir
    • Desteklenen hedefler Lua 5.1, 5.2, 5.3, 5.4 ve luajit’tir
    • Paket yazarının yalnızca uyumlu Lua sürümlerini belirtmesi yeterlidir
  • lux-lib crate’i tamamen gömülebilir ve Lua API’si açığa çıkaracak şekilde de derlenebilir
  • lux.toml dosyasını merkeze alan bir proje kavramı sunar
    • lux.toml üzerinden otomatik olarak rockspec üretir
    • Depoda birden fazla rockspec dosyasını doğrudan yönetme yükünü azaltır
  • Lockfile, tekrarlanabilir derlemeleri ve geliştirme ortamlarını hedefler
    • Kaynak hash’lerini ve rockspec hash’lerini saklar
    • Bu hash’ler Lux’u Nix ile entegre etmeyi kolaylaştırmak için kullanılabilir
  • Kod biçimlendirme ve linting de CLI’nin içine dahildir
  • busted tabanlı test çalıştırmayı varsayılan olarak destekler
    • Neovim, Lua yorumlayıcısı olarak kullanılabilir
    • Temiz bir ortam oluşturur

Luarocks’tan farkları

  • Luarocks geniş kapsamlıdır; ancak yaklaşık 20 yıllık uyumluluk yükü nedeniyle modern Lua geliştirmeye uyarlanması zor bir sorun haline gelmiştir
  • Lux yeni bir başlangıcı hedefler ve ana manifest biçimi olarak TOML kullanır
    • CLI ile bağımlılıklar eklenebilir, kaldırılabilir, sabitlenebilir ve güncellenebilir
    • lux.toml bulunan bir proje dizininde build gibi komutlar projeyi derler ve projenin yerel ağacına kurar
    • Derleme sırasında proje bağımlılıklarının lockfile’ını oluşturarak, uyumlu sistemlerde aynı bağımlılıkların yeniden üretilmesini sağlar
  • SemVer kullanımını teşvik etme biçimi de farklıdır
    • Luarocks, patch sürümünden sonra keyfi sürümlere izin verir
    • Örneğin 1.0.1.0.0.0.2, Luarocks’ta geçerlidir; ancak yararlı bir anlam taşımadığı düşünülür
    • Lux da bunu ayrıştırır, fakat patch sürümünden sonraki değerleri ön sürüm sürümü olarak ele alır
  • Paralel derleme, Nix store’dan ilham alır
    • Lux, paket çakışmalarını önlemek için kurulum dizinlerini hash’ler ve dosya sistemi bozulması riski olmadan paralel derlemeyi mümkün kılar
    • İlgili ayrıntılar Lux’un paket çakışmaları rehberinde bulunur

Neovim ekosisteminde kullanım

  • rocks.nvim ve lazy.nvim’in Luarocks desteğinden sonra Luarocks, Neovim eklentileri için bir dağıtım yöntemi olarak popülerlik kazanıyor
  • Ancak mevcut Luarocks kullanımı tam taşınabilirlikten yoksun ve sonuçları sistemden sisteme öngörmek zor
  • Luarocks Lua ile yazıldığı için çok sayıda paket kurulumu ve rocks.nvim eklenti senkronizasyonu çok yavaştı
  • Lux kullanımı yıkıcı değildir ve Neovim eklentilerinin mevcut Git tabanlı dağıtım şeklini engellemez
  • --nvim bayrağı kullanıldığında paketleri Neovim’in :h packages ile uyumlu bir ağaç yapısına kurar

Nix entegrasyonu için lockfile

  • Neovim eklentileri Luarocks paketi olarak mevcut olduğunda nixpkgs bunu kanonik kaynak olarak kullanır
    • Çünkü uygun bir paket yöneticisinde bağımlılıkları bildirme sorumluluğu paket yazarına aittir
  • Luarocks’un lockfile desteği temeldir ve kaynak hash’i içermez
  • Hem Luarocks hem Lux, luarocks.loader aracılığıyla çakışan bağımlılıkları destekler
  • nixpkgs için aynı bağımlılığın birden fazla sürümünü paket setine makul biçimde eklemek zordur
  • Lux’un lux.lock dosyası her bağımlılığın kaynak hash’ini ve rockspec hash’ini saklar
    • Kaynak URL’si bir Git deposuysa Lux, NAR hash saklar
    • lux.lock, Cargo.lock gibi tüm bağımlılıkları içeren bir fixed-output derivation oluşturmak için kullanılabilir

Sonraki adımlar ve belgeler

  • Şu anki öncelik hata düzeltmeleri ve hata mesajlarının iyileştirilmesidir
  • rocks.nvim, Luarocks yerine Lux’u dahili olarak kullanacak şekilde yeniden yazılacak
    • Bu yeniden yazım, rocks.nvimin hızını diğer eklenti yöneticileriyle aynı seviyeye çıkarmayı hedefliyor
    • Başarılı olursa Lux’un başka yerlere de gömülebileceğini gösteren bir örnek olacak
    • Örnek olarak geçmişte Luarocks ile ilgili sorunlar yaşamış olan lazy.nvim anılıyor
  • İlk kullanıcılar belge sitesinde eğitimleri ve rehberleri görebilir
  • Sorular veya issue’lar GitHub discussions ya da issue tracker üzerinden alınır
  • Lux, LGPLv3.0+ lisanslıdır; Lux logosu ise © 2025 Kai Jakobi’ye ait CC BY-NC-SA 4.0 lisansı kapsamındadır

İlgili okumalar

1 yorum

 
GN⁺ 2025-04-09
Hacker News yorumları

  • Betik dillerinin Aşil topuğu çalıştırma ortamıdır. Kişisel olarak Neovim kullanmıyorum ama Neovim’in benimsenmesinin Lua tarafında bu alanın gelişimini iteceğini düşünmüştüm
    Bryan Cantrill JavaScript’i “C kıyafeti giymiş LISP” diye adlandırmıştı; bazı yönlerden Lua bana bunun tersi gibi geliyor ve bu yüzden hoşuma gidiyor. Yalnız işte kullanmam gerektiği hiç olmadı

    • JavaScript’in C kıyafeti giymiş Lisp olduğu neye dayanıyor bilmiyorum. Lua’nın Lisp’le ne ilgisi var onu da bilmiyorum; Lisp sözdizimi hiç yok

  • Koreader[1] gibi projelerin Lua’yı ana uygulama dili olarak kullandığını biliyorum. Böyle projelerden birini geçiş yapmaya ikna edebilirseniz, bu fikrin olgunluğu ve popülerliği konusunda belli ölçüde güven verebilir
    [1]: https://github.com/koreader/koreader

    • İyi öneri. Lux’ın olgunlaşması için biraz zamana ihtiyacı olacak ama koreader gibi büyük, çok platformlu bir projeyi derlemek kesinlikle iyi bir hedef olabilir

  • Gerçekten iyi görünüyor. Lua’yı çok kullanıyorum; luarocks ise o kadar katı bir yönelime sahip ki ihtiyaç duyduğum işler için neredeyse işe yaramazdı
    “Yerel sistemde doğrudan çalıştırılacak kütüphane kurmak” çizgisinden biraz bile sapınca daha en baştan duvara tosluyorsunuz. Lua paketleri kullanan gömülü bir betik ortamınız varsa ve betikleri bağımlılıklarıyla birlikte paketleyip dağıtmak istiyorsanız vazgeçmeniz gerekiyordu
    Bu aracın o kullanım için daha iyi olup olmadığını bilmiyorum; ama olmasa bile luarocks en iyi ihtimalle hantal ve kullanması sinir bozucu

    • Lua topluluğu C kütüphanelerine inanılmaz derecede bağımlı ve neredeyse tüm luarocks paketleri kütüphane derlemeye çalıştığı için Windows’ta fiilen işe yaramaz hale geliyor

  • İlginç bir proje. Pixi’de conda-forge ekosistemi üzerinden daha iyi Lua desteği oluşturmak için birlikte çalışmak isterim
    Halihazırda lua ve birkaç C eklentisini paketliyoruz. C eklentileri Pixi’nin çekirdek alanlarından biri, bu yüzden iyi uyabilir diye düşünüyorum
    pixi.sh dokümantasyonu ve kayıttaki lua paketi: https://prefix.dev/channels/conda-forge/packages/lua

    • İyi bir fikir gibi görünüyor. Depoda bir issue açtım; oradan rahatça ping atabilirsiniz

  • Burada ya da ilgili sitede göremediğim için soruyorum: package.path ve package.cpath ile yerel olarak entegre oluyor mu, brew(1) gibi standart dışı ama yaygın kullanılan kurulumları algılıyor mu, GitHub :user/:repository biçimiyle kurulum yapılabiliyor mu merak ediyorum
    Proje havalı ve iyi yapılmış görünüyor

    • lx run ve lx lua komutları PATH, LUA_PATH, LUA_CPATH ayarlıyor. Ayrıca bu ortam değişkenlerini ayarlamak için lx path komutu da var
      Lua kurulumunu algılama varsayılan olarak pkg-config kullanıyor; bulamazsa lua_src ve luajit_src crate’leriyle Lua kurmayı deniyor. İleride vcpkg gibi başka araçlar için destek de eklenebilir
      GitHub :user/:repository kurulumu henüz yok. Bunu lux.toml/bağımlılık tanımına ekleme planı var; ama bu biçimdeki rockspec’leri luarocks.org’da yayımlamaya muhtemelen izin vermeyeceğim. Çünkü insanları luarocks ile derlenemeyen paketler yüklemeye teşvik eden kişi olmak istemiyorum

  • C’ye gömülmek üzere tasarlanmış ve C kütüphanelerine büyük ölçüde dayanan bir dil için paket yöneticisi Rust ile yazılıyor, Lua’nın kendisi C programları için yapılandırma dili olarak yaratılmışken yapılandırma TOML ile mi yapılıyor
    Kalsın. Luarocks’un sınırları var ve muhtemelen yeniden yazılması gerekir; ama ekosisteme uygun bir dil kullanılmalı ve Lua ekosisteminin kültürü izlenmeli. Rust ve Cargo, Lua’nın tam karşı tarafında duruyor

    • Lua evrildi ve ilk yaratıldığı amacın çok ötesinde yerlerde kullanılıyor

  • Kişisel olarak bu tür dile özel paket yöneticilerinden çok sıkıldım. Doğru yön gibi gelmiyor; nix gibi bir yaklaşım çok daha iyi görünüyor

    • Lux’ın motivasyonlarından biri nixpkgs’deki Lua ve Neovim ekosistemini iyileştirmek

  • Rust’a bağımlı bir Lua paket yöneticisi ha

    • Pek sorun gibi görünmüyor. Çoğu paket yöneticisi yalnızca ikili paket kurulumu destekler
    • Beklediğinizden iyi çalıştığını görünce şaşırabilirsiniz
    • Üstelik TOML de kullanıyor

  • Hoşuma gitti. Epey zamandır birden fazla makinede tekrarlanabilir Lua paket kurulumu yöntemi istiyordum

    • Birden fazla makinede tekrarlanabilir Lua paket kurulum durumu oluşturdum; ama Lua’yı çoğunlukla iki şekilde kullanıyorum
      Biri, “ham” biçimde iç VM’e linkleyip proje derlemesinin bir parçası olarak .lua kod tabanını yönetmek; diğeri ise sistem aracı olarak kullanıp luarocks --local, luaenv gibi araçları uygun şekilde Makefile/CMakeLists.txt içine koymak ve dağıtım paketleri için luastatic’i biraz devreye almak
      Dürüst olmak gerekirse bu Python’dan ya da birlikte gömülebilecek başka betik dillerinden çok farklı değil. Ancak sistemin sağladığı /bin/script_language ile, daha büyük bir proje içindeki geliştirme aracı/betik motoru ya da yerel çalışma tezgâhı aracı olarak kullanılan dili her zaman ayırmak gerekiyor
      Lua’yı gerçekten sevmemin nedenlerinden biri, kütüphaneleri paketleyip, bytecode’u linkleyip, paketi sararak hedef işletim sistemi kullanıcısına tek tıkla kurulum biçiminde sunmanın oldukça kolay ve keyifli olması. Elbette bir miktar elinizi taşın altına koymanız gerekiyor

  • Harika sayılır ama Lua’nın tasarım yönünün tersine gidiyormuş gibi güçlü bir his veriyor. Lua basit bir gömülebilir dil olarak tasarlandı; burada “paket yönetimi” birkaç zip indirip açmaktan ibaret, “sürüm yönetimi” ise 5.1 uyumlu mu yoksa 5.4 uyumlu mu kullanacağını seçmeye daha yakın