Neovim Pack

(neovim.io)

1 puan yazan GN⁺ 2025-09-06 | 1 yorum | WhatsApp'ta paylaş

Neovim, deneysel yerleşik eklenti yöneticisi vim.pack'i sunarak ayrı bir harici yönetici olmadan eklenti kurulumunu, sürüm yönetimini ve kaldırma işlemlerini entegre şekilde sağlıyor
(İlk test aşamasında olduğundan API sık sık değişebilir)

Başlıca özellikler

Yalnızca $XDG_DATA_HOME/nvim/site/pack/core/opt dizinini yönetir
Eklentiler mutlaka Git deposu biçiminde olmalı ve git komutu gereklidir (en az sürüm 2.36)
Eklenti sürümleri semver etiketleri (v1.2.3 biçimi) veya branch/commit hash ile belirtilebilir
Kurulum, güncelleme, silme, sürümü sabitleme (freeze) gibi tüm işlemler yerleşik fonksiyonlarla yapılır

Kurulum ve güncelleme çalışma şekli

vim.pack.add() çağrısını init.lua içine ekleyin (birden fazla biçim desteklenir)
Neovim yeniden başlatıldığında kurulum otomatik olarak yapılır
vim.pack.update() çağrıldığında en son sürüme toplu güncelleme yapılabilir

Güncelleme kontrolü, önizleme (LSP tabanlı), konsoldan onay/iptal desteği sunulur

Sürüm değiştirirken init.lua içindeki sürüm tanımını güncelledikten sonra vim.pack.update({ 'eklenti_adı' }) çalıştırın
Sürüm freeze işlemi mevcut commit hash'e göre belirlenir
Kaldırma işlemi vim.pack.del() çağrısıyla yapılır

API'nin başlıca parametreleri ve davranışı

add: Eklenti listesini alır; yoksa git clone ile indirir ve sürümü checkout eder
güncelleme: force bayrağıyla anında/onarım pencereli mod arasında seçim yapılabilir; değişiklik geçmişi nvim-pack.log içinde tutulur
Her olayda (kurulum/güncelleme/silme) hook sağlanır ve eklenti meta bilgileri açığa çıkarılır

Notlar

Üretim ortamında deneysel bir yönetici olduğu için davranışlar aniden değişebilir
Eklenti diskte zaten bulunsa bile gerçek sürüm ile belirtilen sürüm uyuşmayabilir; bu yüzden update ile senkronizasyon gereklidir
Kaldırma sırasında yeniden yüklenmesini önlemek için add içindeki tanım da kaldırılmalıdır

1 yorum

GN⁺ 2025-09-06

Hacker News görüşleri

Bu güncellemeyi büyük bir heyecanla bekliyorum; umarım nvim eklenti topluluğu, karmaşık bir eklenti yöneticisi olan lazy'yi kullanmadan eklentileri varsayılan olarak lazy loading yapacak şekilde gelişir. nvim resmi belgelerinde de bununla ilgili notlar var; bkz. nvim lazy loading resmi dokümanı. Kişisel olarak nvim-neorocks eklentisinin önerdiği best practice'leri de çok beğeniyorum: nvim-neorocks best practices. Son zamanlarda bunların bir kısmı resmi olarak birleştirilmiş gibi görünüyor: neovim PR #29073
- neovim'de setup() modeli kullanıldığı için lazy loading, eski Vim yaklaşımına göre daha zorlayıcı geliyor. Vim'de sadece değişkenleri ayarlarsınız, fonksiyon çalıştığında eklenti kendiliğinden yüklenir. Lua tabanlı yapıda ise birden fazla autocmd aynı eklentiye referans verdiğinde hepsinin setup() çağrısını doğrudan yapması gerekiyor; bu da biraz daha fazla orkestrasyon gerektiriyor
Yaklaşık her 3 yılda bir (Neo)Vim paket yöneticisi değiştiriyormuşum gibi hissediyorum; yolculuğum pathogen → Vundle → vim-plug → lazy.nvim şeklindeydi. Umarım bu son Vim paket yöneticim olur
- Plug'ın hâlâ gayet kullanılabilir olduğunu düşünüyorum. Bu yerleşik sürüm, dilin içine gömülü olduğu için daha fazla kullanıcıyı memnun edecek bir endgame olabilir. Kendim denedim; lazy'nin sunduğu özel özellikleri kullanmamış olsam da sorunsuz çalıştı
- Nihayet resmi olarak yerleşik bir resmi paket yöneticisinin gelmesine sevindim. Bundan sonra en geniş desteği görmesi ve en yaygın kullanılan seçenek olması muhtemel görünüyor (tabii özellik zenginliği farklı olabilir)
- lazy.nvim'in de çok güçlü olduğunu düşünüyorum. Ama birçok eklenti farklı paket yöneticilerini ayrı ayrı desteklediği için bir miktar standartlaşmaya da ihtiyaç var. lazy.nvim kadar hızlı ve güven veren bir şey ortaya çıkar mı emin değilim ama imkânsız da görünmüyor
- Ben nixvim kullanmaya başladım; vim-plug dönemlerinde artık pes etmiştim. Birden fazla makinede ve farklı işletim sistemlerinde ayarları sürekli düzgün tutmak tam bir eziyetti
- Nix'te her zaman aynı şekilde çalışıyor. NixOS, MacOS ve Linux üzerindeki nix-managed home-manager'da şu şekilde yapılandırılabiliyor
```
neovim = {
  enable = true;
  vimAlias = true;
  vimdiffAlias = true;
  defaultEditor = true;
  plugins = [
    pkgs.vimPlugins.fugitive
    pkgs.vimPlugins.fzf-vim
    pkgs.vimPlugins.vim-gh-line
    pkgs.vimPlugins.vim-gutentags
    pkgs.vimPlugins.nvim-lspconfig
    pkgs.pkgs-unstable.vimPlugins.vim-go
    pkgs.pkgs-unstable.vimPlugins.zig-vim
  ];
  extraConfig = builtins.readFile ./vimrc;
  extraLuaConfig = builtins.readFile (pkgs.replaceVars ./dev.lua {
    inherit (pkgs) ripgrep;
  }).outPath;
}
```
Neovim kullanıcılarına faydası olur diye yakın zamanda lazy.nvim'den yalnızca vim.pack kullanan bir yapıya geçtim: bu Pull Request'e bakın. Hiç sorun yaşamadım ve yaklaşık 50 eklenti kullanıyorum. Beklediğimden çok daha kolaydı; bir arkadaşım da yardım etti ve lazy'ye benzer şekilde eklentileri yükleyen bir yapı kurduk. Özellikle iş bilgisayarımda lazy.nvim ile 300ms süren eklenti yükleme artık 80ms'ye kadar düştü
- Bilgi olsun, ilgili bağlantı diff içinde alakasız bir dosyaya gidiyor
Git'ten kod import edilebilmesi ve hatta branch ya da commit hash belirtilebilmesi gibi özellikleri her gördüğümde, “belirli bir andaki branch checkout'u” özelliğinin belgelenmesini istiyorum. Birçok Vim eklentisi branch'i sürüm yönetimi bile yapmıyor. Örneğin git checkout 'master@{2025-05-26 18:30:00}' gibi belirli bir datetime'a göre checkout yapmak mümkün. Dileğim, bunun leftPad faciası ya da xz güvenlik olayı gibi sürüm yönetimi başarısızlıklarını önlemeye yardımcı olması
- İlginç bir fikir gibi geliyor ama “hangi zamanın saatini baz alıyoruz?” sorusu aklıma geliyor. Depoya ait saati mi, benim bilgisayarımın saatini mi, yoksa uzak git sunucusunun saatini mi? Genel olarak hash kullanmak daha doğru ama zaman temelli yazılım geliştirmeyi önermem (son çare değilse)
- Tedarik zinciri saldırıları açısından riskin ne olduğunu merak ediyorum; VIM eklentilerinin ne düzeyde yetkiye sahip olduğunu bilmek isterim
- Belirttiğiniz andaki master'ı checkout etmek, o andaki durumu almak yerine benim pull yaptığım ana göre davranıyormuş gibi geliyor; bu da kafa karıştırıcı (tekrarlanabilir değil). Gerçek anlamda tekrarlanabilirlik istiyorsanız git log —before=time gibi daha karmaşık yöntemler gerekir
- Neden doğrudan SHA kullanılmıyor diye merak ediyorum
Vim eklenti yöneticisi şart değil, özellikle de dotfiles'ınızı git ile yönetiyorsanız. Eklenti dosyalarını belirli bir dizine clone etmeniz yeterli. Yapılandırmayı da git ile yönetiyorsanız, git submodule ile eklenti sürümlerini sabitleyip takip edebilirsiniz. Bu yöntem version pinning açısından da avantajlı
- Ben de 1 yıl boyunca git submodule kullandım. Beni motive eden fikir, araçlara özel tüm paket yöneticilerini submodule ile değiştirebileceğim düşüncesiydi (vim, tmux, zsh vb.). Ama pratikte submodule yönetimi, vim-plug'a kıyasla çok daha zahmetliydi. Fikir güzel ama Git'in ergonomisi zayıf. Sonunda geri döndüm. Yerleşik vim pack'i kullanıp da vim-plug'dan bile daha rahat ettiğini söyleyen varsa deneyimini paylaşmasını isterim
- Benim sık sık eklenti açıp kapatma ihtiyacım var; bu yüzden basit dosya sistemi yerine config üzerinden yönetmek daha rahat geliyor. Ayrıca dosya tipine göre eklenti etkinleştirmek de kolay. Aslında çoğu eklenti yöneticisinin sonuçta git için bir wrapper'dan ibaret olduğunu düşünüyorum
Henüz ham bir durumda. Ama lazy'den vazgeçeceğim gün gelirse deferred load'un uygulanmış olmasını isterim. lazy.nvim'in açıkça harika olduğunu düşünüyorum ama son zamanlarda yazarın snack.nvim, mini.nvim gibi popüler açık kaynak eklentileri doğrudan kendisinin yeniden yaparak kullanıcı kilitleme davranışı sergilediğini hissediyorum. Bu tür copycat/kill zone stratejilerini anlamıyorum
- Hatta bazı paketlerin bakımını da yapmıyor ve kaderine bırakıyor (ör. snacks). Bu arada mini.nvim tamamen farklı bir yazarın işi; lazy ile ayrı
- Yine de lazy'nin yazarının kendi tarzında yüksek kaliteli arayüzler üretme becerisine sahip olduğunu düşünüyorum. Ben bu tarzı oldukça seviyorum ve çoğu zaman en iyisi olduğunu düşünüyorum. Örneğin Snacks picker gerçekten en iyi seçeneklerden biri oldu
Eski bir vim kullanıcısıyım ama neovim'i eklentilerle kullanmanın sonunda pek iyi bir fikir olmadığına karar verdim. Bir şeyler sürekli bozuluyor. Bunun yerine çekirdek eklentilerin (LSP, tree sitter) doğrudan native olarak entegre edilmesi durumunda neovim'in daha iyi ilerleyeceğini düşünüyorum
- Ben de bir süre böyle hissettim ve C/C++ geliştirmede vim-plug, gutentags(ctags) ve ALE ile idare ettim. Ama web geliştirmede birden fazla sözdizimi ve araç kullanmak zorunda kalınca sonunda bir neovim dağıtımına geçtim. Çeşitli dağıtımları denedim; artık geliştirilmeyen Lunarvim ve şu anda da Astronvim bana iyi uydu
- Aslında tree-sitter ve LSP zaten native olarak entegre edilmiş durumda. Başlıca LSP/tree-sitter eklentileri sadece varsayılan ayarlar ve query bundle'ları sağlıyor; ileride nvim-treesitter'a bağımlı olmamak için query'lerin bizzat neovim tarafından native olarak paketlenmesi de planlanıyor. LSP yapılandırması da artık çok kolay; örneğin
```
vim.lsp.config("expert", {
  cmd = { "expert" },
  root_markers = { "mix.exs", ".git" },
  filetypes = { "elixir", "eelixir", "heex" },
})
vim.lsp.enable("expert")
```
  Ayrıca "LspAttach" autocmd içinde LSP başına keymap ayarları da yapılabiliyor
- Bence önümüzdeki 5-10 yıl içinde bu karmaşa toparlanır
Oldukça uzun süredir kullanıyorum ve hiçbir sorun yaşamadım: dotfiles'ıma bakın
Açıkçası ille de minimalist olmak zorunda değil; başka özel bir sebep yoksa birleşik bir çözüm olmasını tercih ederim. Şu anda vim pack ile git submodule'ü birlikte kullanıyorum ama hangi GitHub projesinin en iyi/tavsiye edilen/iyi desteklenen seçenek olduğu konusunda kafam karışıyor; bir daha nvim paket yöneticisi seçmek istemiyorum
Bunun eklendiği orijinal issue şu: neovim resmi issue #20893. Neovim projesi için uzun süredir hedeflerden biriymiş gibi görünüyor ama nedenine dair bir açıklama yoktu. Açıkçası mevcut eklentiler zaten bu işi çok iyi yaptığı için biraz gereksiz şişkinlik (bloat) gibi gelmişti. Ama görünüşe göre herkes aynı fikirde değil
- Açıklama aslında o issue içinde yer alıyor, bakmak isteyebilirsiniz: ilgili issue açıklaması

Neovim Pack

Başlıca özellikler

Kurulum ve güncelleme çalışma şekli

API'nin başlıca parametreleri ve davranışı

Notlar

İlgili okumalar

1 yorum

Hacker News görüşleri