Neovim Pack

(neovim.io)

1 Punkte von GN⁺ 2025-09-06 | 1 Kommentare | Auf WhatsApp teilen

Neovim führt mit vim.pack einen experimentellen integrierten Plugin-Manager ein, der Installation, Versionsverwaltung und Entfernung von Plugins ohne separaten externen Manager gebündelt bereitstellt
(Da sich alles noch in einer frühen Testphase befindet, kann sich die API häufig ändern)

Hauptmerkmale

Ausschließliche Verwaltung des Verzeichnisses $XDG_DATA_HOME/nvim/site/pack/core/opt
Plugins müssen zwingend im Format eines Git-Repositories vorliegen; der git-Befehl (mindestens Version 2.36) ist erforderlich
Plugin-Versionen können über semver-Tags (in der Form v1.2.3) oder über Branches/Commit-Hashes angegeben werden
Alle Vorgänge wie Installation, Update, Entfernung und Versionsfixierung (freeze) werden über integrierte Funktionen ausgeführt

Funktionsweise von Installation und Updates

vim.pack.add() zu init.lua hinzufügen (mehrere Formate werden unterstützt)
Beim Neustart von Neovim wird die Installation automatisch durchgeführt
Mit dem Aufruf von vim.pack.update() lassen sich alle Plugins gesammelt auf die neueste Version aktualisieren

Unterstützung für Update-Prüfung, Vorschau (LSP-basiert) sowie Bestätigung/Abbruch in der Konsole

Bei einer Versionsänderung die Versionsangabe in init.lua anpassen und danach vim.pack.update({ 'Pluginname' }) ausführen
Das Versions-freeze wird anhand des aktuellen Commit-Hashes festgelegt
Das Entfernen erfolgt über den Aufruf von vim.pack.del()

Wichtige API-Parameter und Verhalten

add: Nimmt eine Plugin-Liste entgegen, lädt bei Bedarf per git clone herunter und checkt die angegebene Version aus
Update: Mit dem Flag force kann zwischen Sofortmodus und Bestätigungsdialog gewählt werden; Änderungen werden in nvim-pack.log protokolliert
Für jedes Ereignis (Installation/Update/Entfernung) werden Hooks bereitgestellt, außerdem werden Plugin-Metadaten offengelegt

Hinweise

In Produktionsumgebungen ist Vorsicht geboten, da es sich um einen experimentellen Manager handelt und sich das Verhalten unerwartet ändern kann
Selbst wenn sich ein Plugin bereits auf der Festplatte befindet, können tatsächliche und angegebene Version voneinander abweichen; daher ist eine Synchronisierung per Update erforderlich
Beim Entfernen muss die Spezifikation auch aus add entfernt werden, damit keine Neuinstallation erfolgt

1 Kommentare

GN⁺ 2025-09-06

Hacker-News-Kommentare

Ich freue mich sehr auf dieses Update und hoffe, dass sich die nvim-Plugin-Community dahin entwickelt, Plugins standardmäßig lazy zu laden, ohne dafür einen komplexen Plugin-Manager wie lazy zu verwenden. Dazu gibt es auch einen Hinweis in der offiziellen nvim-Dokumentation: offizielle nvim-Dokumentation zu Lazy Loading. Persönlich gefallen mir auch die vom nvim-neorocks-Plugin vorgeschlagenen Best Practices sehr gut: nvim-neorocks Best Practices. Kürzlich scheint ein Teil davon offiziell übernommen worden zu sein: neovim PR #29073
- Durch das setup()-Modell in neovim wirkt Lazy Loading komplizierter als im klassischen Vim-Stil. In Vim setzt man nur Variablen, und das Plugin wird automatisch geladen, wenn eine Funktion ausgeführt wird. In der Lua-basierten Welt muss man, wenn mehrere autocmd dasselbe Plugin referenzieren, setup() jeweils selbst aufrufen, was etwas mehr Orchestrierung erfordert.
Ich habe das Gefühl, dass ich ungefähr alle drei Jahre den (Neo)Vim-Paketmanager wechsle. Meine Reise war pathogen → Vundle → vim-plug → lazy.nvim. Hoffentlich ist das nun mein letzter Vim-Paketmanager.
- Ich finde, Plug ist immer noch brauchbar. Die jetzt eingebaute Variante ist direkt in die Sprache integriert und könnte als Endgame mehr Nutzer zufriedenstellen. Ich habe sie selbst ausprobiert; ich habe keine der speziellen Funktionen genutzt, die lazy bietet, aber sie hat solide und problemlos funktioniert.
- Ich freue mich, dass es endlich ein offiziell integrierter offizieller Paketmanager ist. Ich denke, dass er künftig am breitesten unterstützt und genutzt werden wird, auch wenn der Funktionsumfang natürlich abweichen kann.
- Ich halte lazy.nvim ebenfalls für sehr leistungsfähig. Aber weil viele Plugins jeweils verschiedene Paketmanager unterstützen, braucht es auch ein gewisses Maß an Vereinheitlichung. Ich bin mir nicht sicher, ob etwas entstehen kann, das so schnell und vertrauenswürdig ist wie lazy.nvim, aber unmöglich scheint es nicht zu sein.
- Ich habe angefangen, nixvim zu verwenden. Zur Zeit von vim-plug hatte ich einfach aufgegeben. Es war mühsam, die Konfiguration über mehrere Maschinen und verschiedene Betriebssysteme hinweg zuverlässig konsistent zu halten.
- Mit Nix funktioniert es immer auf die gleiche Weise. In NixOS, MacOS und Linux mit nix-managed home-manager kann man es so konfigurieren:
```
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;
}
```
Falls es neovim-Nutzern hilft: Ich bin kürzlich von lazy.nvim auf eine reine vim.pack-Nutzung migriert: siehe diesen Pull Request. Es gab überhaupt keine Probleme, ich nutze nur etwa 50 Plugins, und es war deutlich einfacher als erwartet. Mit Hilfe eines Bekannten habe ich eine Konfiguration gebaut, bei der Plugins ähnlich wie in lazy geladen werden. Besonders auf meinem Arbeitsrechner ist die Plugin-Ladezeit von 300 ms mit lazy.nvim auf jetzt 80 ms gesunken.
- Der verlinkte Verweis führt übrigens im Diff auf eine nicht zugehörige Datei.
Immer wenn ich sehe, dass man Code aus git importieren und sogar Branches oder Commit-Hashes angeben kann, wünsche ich mir eine Dokumentation für die Funktion „Branch zu einem bestimmten Zeitpunkt auschecken“. Viele Vim-Plugin-Branches werden nicht einmal versioniert. Zum Beispiel kann man mit git checkout 'master@{2025-05-26 18:30:00}' einen Checkout passend zu einem bestimmten Datum und einer Uhrzeit machen. Dahinter steckt für mich die Hoffnung, Ausfälle der Versionsverwaltung wie bei leftPad oder dem xz-Sicherheitsvorfall zu vermeiden.
- Klingt nach einer interessanten Idee, aber ich frage mich: Von wessen Uhr sprechen wir dabei? Von der Uhr des Repositories, meines Rechners oder einer entfernten git-Uhr? Normalerweise sollte man dafür Hashes verwenden; zeitbasierte Softwareentwicklung würde ich nicht empfehlen, außer als allerletzten Ausweg.
- Mich würde das Risiko durch Supply-Chain-Angriffe interessieren. Ich würde gern wissen, welche Rechte VIM-Plugins eigentlich haben.
- Wenn man den Stand von master zu einem bestimmten Zeitpunkt auscheckt, holt man ihn nicht wirklich zu diesem Zeitpunkt, sondern bezogen auf den Zeitpunkt des Pulls, was verwirrend ist und nicht reproduzierbar. Wenn man echte Reproduzierbarkeit will, braucht man kompliziertere Wege wie git log —before=time und Ähnliches.
- Warum nicht einfach den SHA verwenden?
Einen Vim-Plugin-Manager braucht man nicht zwingend, besonders wenn man seine Dotfiles mit git verwaltet. Man muss die Plugin-Dateien nur in ein bestimmtes Verzeichnis klonen. Wenn man auch die Konfiguration mit git verwaltet, kann man Plugin-Versionen mit git submodules fixieren und nachverfolgen. Diese Methode ist auch für Version Pinning vorteilhaft.
- Ich habe auch ein Jahr lang git submodule verwendet. Die Motivation war die Idee, alle werkzeugspezifischen Paketmanager durch Submodule zu ersetzen (vim, tmux, zsh usw.). Praktisch war die Verwaltung von Submodulen im Vergleich zu vim-plug jedoch sehr umständlich. Das Konzept ist gut, aber Git ist ergonomisch schwach. Am Ende bin ich wieder zurückgegangen. Falls jemand die eingebaute vim-pack-Funktion nutzt und sie als noch komfortabler als vim-plug empfindet, würde ich diesen Erfahrungsbericht gern hören.
- Ich muss Plugins häufig an- und ausschalten, deshalb ist eine Konfiguration dafür bequemer als ein bloßes Dateisystem. Außerdem lassen sich Plugins je nach Dateityp leicht aktivieren. Eigentlich sind die meisten Plugin-Manager ohnehin nur Wrapper um git.
Es ist noch ziemlich primitiv, aber falls der Tag kommt, an dem ich lazy aufgebe, hätte ich gern implementiertes Deferred Loading. lazy.nvim ist zweifellos großartig, aber in letzter Zeit wirkt es auf mich so, als würde der Autor durch eigene Implementierungen bekannter Open-Source-Plugins wie snack.nvim und mini.nvim ein Nutzer-Lock-in betreiben. Ich verstehe diese Copycat-/Kill-Zone-Strategie nicht.
- Manche Pakete lässt er sogar ungewartet liegen (z. B. snacks). Und nur zur Klarstellung: mini.nvim hat einen ganz anderen Autor und ist von lazy unabhängig.
- Trotzdem finde ich, dass der Autor von lazy die Fähigkeit hat, auf seine Weise hochwertige Interfaces zu bauen. Mir gefällt dieser Ansatz ziemlich gut, sodass ich oft denke, dass es die beste Lösung ist. Der Snacks-Picker ist dafür ein gutes Beispiel und für mich die beste Wahl.
Ich bin ein langjähriger Vim-Nutzer, aber ich bin zu dem Schluss gekommen, dass neovim mit Plugins am Ende doch nicht so toll ist. Irgendetwas geht ständig kaputt. Lieber hätte ich gesehen, dass Kern-Plugins wie LSP und tree sitter nativ integriert werden; ich glaube, damit würde neovim deutlich besser dastehen.
- Ich hatte denselben Eindruck und bin für C/C++-Entwicklung mit vim-plug, gutentags (ctags) und ALE ganz gut zurechtgekommen. Als ich dann Webentwicklung mit vielen verschiedenen Syntaxen und Tools gemacht habe, bin ich letztlich auf eine neovim-Distribution umgestiegen. Ich habe mehrere Distributionen ausprobiert; das inzwischen eingestellte Lunarvim und aktuell Astronvim haben für mich gut gepasst.
- Tatsächlich sind tree-sitter und LSP bereits nativ integriert. Die wichtigsten LSP-/tree-sitter-Plugins liefern im Wesentlichen nur Default-Konfigurationen und gebündelte Queries, und künftig plant neovim offenbar, die Queries selbst nativ mitzuliefern, sodass keine Abhängigkeit von nvim-treesitter mehr nötig ist. Auch die LSP-Konfiguration ist sehr einfach geworden, zum Beispiel:
```
vim.lsp.config("expert", {
  cmd = { "expert" },
  root_markers = { "mix.exs", ".git" },
  filetypes = { "elixir", "eelixir", "heex" },
})
vim.lsp.enable("expert")
```
  Und im "LspAttach"-autocmd kann man auch LSP-spezifische Keymaps setzen.
- Ich schätze, dass sich das in den nächsten 5 bis 10 Jahren bereinigen wird.
Ich nutze das schon ziemlich lange und hatte überhaupt keine Probleme: siehe meine Dotfiles
Ehrlich gesagt muss es gar nicht unbedingt minimalistisch sein; wenn es keinen besonderen Grund dagegen gibt, hätte ich lieber eine integrierte Lösung. Derzeit nutze ich vim pack zusammen mit git submodules, aber ich möchte nicht schon wieder einen nvim-Paketmanager auswählen müssen, nur weil unklar ist, welches GitHub-Projekt optimal, empfohlen oder gut unterstützt ist.
Das ist das ursprüngliche Issue, in dem es hinzugefügt wurde: offizielles neovim-Issue #20893. Es scheint im neovim-Projekt schon lange ein Ziel gewesen zu sein, aber warum genau, wurde nicht erklärt. Ehrlich gesagt wirkte es auf mich wie unnötiger Ballast, weil bestehende Plugins diese Aufgabe bereits hervorragend erfüllt haben. Einige sahen das allerdings offenbar anders.
- Die Erklärung steht in diesem Issue selbst: Beschreibung in diesem Issue

Neovim Pack

Hauptmerkmale

Funktionsweise von Installation und Updates

Wichtige API-Parameter und Verhalten

Hinweise

Verwandte Beiträge

1 Kommentare

Hacker-News-Kommentare