Neovim Pack

(neovim.io)

1P by GN⁺ 3일전 | ★ favorite | 댓글 1개

Neovim은 실험적 내장 플러그인 매니저인 vim.pack을 도입하여, 별도 외부 매니저 없이 플러그인 설치·버전관리·삭제 기능을 통합 제공함
(초기 테스트 단계이므로, 자주 API가 변경될 수 있음)

주요 특징

$XDG_DATA_HOME/nvim/site/pack/core/opt 디렉토리 전용 관리
플러그인은 반드시 Git 리포지토리 형식이어야 하며, git 명령어(최소 2.36 버전 이상) 필수
플러그인 버전은 semver 태그(v1.2.3 형태)나 브랜치/커밋 해시 등으로 지정 가능
설치, 업데이트, 삭제, 버전 고정(freeze) 등 모든 작업을 내장 함수로 처리

설치 및 업데이트 동작 방식

vim.pack.add()를 init.lua에 추가(여러 형식 지원)
Neovim 재시작 시 자동 설치 처리
vim.pack.update() 호출 시 최신 버전으로 일괄 업데이트 가능

업데이트 검사, 미리보기(LSP기반), 콘솔에서 확인/취소 지원

버전 변경 시, init.lua 내의 버전 지정 수정 후, vim.pack.update({ '플러그인명' }) 실행
버전 freeze는 현재 커밋 해시 기준으로 지정
삭제는 vim.pack.del() 호출로 처리

API 주요 파라미터 및 동작

add: 플러그인 목록 받아, 없으면 git clone 다운로드 및 version 체크아웃
업데이트: force 플래그로 즉시/확인 대화 모드 선택 가능, 변경 내역은 "nvim-pack.log"에 남음
각 이벤트(설치/업데이트/삭제)시 hook 제공, 플러그인 메타 정보 노출

참고 사항

프로덕션에선 실험적 매니저이므로 갑작스러운 동작변경 가능성 있음
이미 디스크에 플러그인이 있더라도, 실제 버전과 지정 버전이 불일치할 수 있으므로 update 동기화 필수
삭제시 add에서 사양을 제거해야 재설치 방지 가능

▲

GN⁺ 3일전 [-]

Hacker News 의견

이번 업데이트를 굉장히 기대하고 있음, nvim 플러그인 커뮤니티가 복잡한 플러그인 매니저인 lazy를 사용하지 않고 플러그인을 기본적으로 lazy loading하도록 발전하길 바람, nvim 공식 문서에도 관련 노트가 있으니 참고했으면 좋겠음 nvim lazy loading 공식 문서 참고, 개인적으로 nvim-neorocks 플러그인에서 제안한 best practices도 매우 좋아함 nvim-neorocks best practices 최근 이 중 일부가 공식적으로 병합된 듯함 neovim PR #29073
- neovim에서 setup() 모델을 사용하다 보니, lazy loading이 기존 Vim 방식보다 까다로워진다는 느낌임, Vim은 변수만 설정하면 함수가 실행될 때 알아서 플러그인이 로드됨, lua 기반에서는 여러 autocmd가 동일 플러그인을 참조할 때 모두 setup()을 직접 호출해야 해서 오케스트레이션이 조금 더 필요해짐
(Neo)Vim 패키지 매니저를 약 3년에 한 번씩 옮겨 다니고 있는 느낌임, 내 여정은 pathogen → Vundle → vim-plug → lazy.nvim순서였음, 이번이 마지막 Vim 패키지 매니저였으면 좋겠음
- Plug도 여전히 쓸만하다고 생각함, 이번 내장 버전은 언어에 내장되어 있어 더 많은 사용자를 만족시킬만한 엔드게임이라고 생각함, 직접 사용해봤는데 lazy에서 제공하던 특별한 기능은 안 써봤지만 무난하게 잘 동작했음
- 드디어 공식적으로 내장된 공식 패키지 매니저인 점이 반가움, 앞으로 가장 널리 지원되고 사용될 가능성이 높다고 봄 (물론 기능 풍부함은 다를 수 있음)
- lazy.nvim 역시 매우 강력하다고 생각함, 하지만 여러 플러그인이 각각 다양한 패키지 매니저를 지원하므로 어느 정도 통일성도 필요하다고 생각함, lazy.nvim 만큼 빠르고 신뢰감 있는 게 생길 수 있을지 의문이지만, 불가능하진 않을 느낌임
- 나는 nixvim을 사용하기 시작했음, vim-plug 때쯤에 그냥 포기했었음. 여러 대의 머신과 다양한 OS에서 설정을 항상 잘 유지하는 게 고역이었음
- Nix에서는 언제나 동일한 방식으로 동작함. NixOS, MacOS, Linux의 nix-managed home-manager에서 다음처럼 설정 가능함
```
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 유저들에게 도움이 될까 해서 최근 lazy.nvim에서 vim.pack만 사용하는 방식으로 마이그레이션했음 이 Pull Request 참고, 문제 전혀 없었고 플러그인은 50개 정도만 사용함, 예상보다 훨씬 쉽고 지인도 도와서 lazy와 비슷하게 플러그인이 로드되는 설정을 만들었음, 특히 업무용 컴퓨터에서 lazy.nvim으로 300ms 걸리던 플러그인 로딩이 이제는 80ms까지 줄어듦
- 참고로 해당 링크는 diff에서 관련 없는 파일로 연결되고 있음
git에서 코드 임포트가 가능하고, 브랜치나 커밋 해시까지 지정할 수 있는 기능이 있는 것을 볼 때마다 “특정 시점의 브랜치 체크아웃” 기능에 대한 문서화를 바람, 많은 Vim 플러그인 브랜치는 버전 관리도 안 하는 경우가 있음, 예를 들어 git checkout 'master@{2025-05-26 18:30:00}' 식으로 특정 datetime에 맞춰 체크아웃할 수 있음, 이는 leftPad 대참사나 xz 보안 사고처럼 버전 관리 실패를 예방해주길 바라는 마음임
- 흥미로운 아이디어처럼 들리지만, “어느 시점의 시계를 기준으로 하는가?”라는 의문이 듦, 레포지토리 본연의 시계인지, 내 컴퓨터 시계인지 아니면 원격 git 시계인지가 중요함, 일반적으로 해시로 하는 것은 맞지만 시간 기반 소프트웨어 개발은 추천하지 않음 (최후의 수단 아니면)
- 공급망 공격에 대한 위험성이 궁금함, VIM 플러그인은 어느 정도의 권한을 가지는지 알고 싶음
- 지정한 시점의 master를 체크아웃하면 그 때 가져오는 게 아니라, 내가 pull하는 시점 기준이 되어 혼란스러움 (재현성 없음), 진정한 재현성을 원한다면 git log —before=time 등 더 복잡한 방법이 필요함
- 단순히 SHA로 하면 안 되는지 궁금함
Vim 플러그인 매니저는 꼭 필요하지 않음, 특히 dotfiles를 git으로 관리할 경우임, 플러그인 파일을 지정 디렉터리에 clone만 하면 됨, 설정도 git으로 관리하면 git submodules로 플러그인 버전을 고정해서 트래킹할 수 있음. 이 방식이 버전 pinning에도 유리함
- 나도 1년간 git submodule을 이용했었음, 모든 툴 특화된 패키지 매니저를 submodule로 대체할 수 있다는 생각이 동기였음 (vim, tmux, zsh 등), 그러나 실질적으로 submodule 관리는 vim-plug 대비 매우 번거로웠음, 개념은 좋은데 Git에서 ergonomics가 떨어짐, 결국 다시 되돌아감. 내장된 vim pack을 써서 vim-plug보다도 더 편하게 느껴진 경험담이 있으면 공유해주길 바람
- 나는 플러그인을 자주 켜고 끄는 필요가 있어서 단순 파일시스템보다 config로 하는 게 편함, 그리고 파일 타입에 따라 플러그인 활성화가 쉬움, 사실 대부분 플러그인 매니저도 결국 git의 래퍼에 불과하다고 생각함
아직 원시적이던 상태임, 다만 lazy를 버리게 될 날이 오면 deferred load가 구현되었으면 함, lazy.nvim은 분명 훌륭하지만, 최근 저자는 snack.nvim, mini.nvim 같은 유명 오픈소스 플러그인들을 직접 다 구현해버리며 사용자 락인 행태를 보인다고 느낌, 이런 카피캣/킬존 전략이 이해가 안 감
- 심지어 일부 패키지는 유지 관리도 안 하고 방치함 (예: snacks), 참고로 mini.nvim은 완전히 다른 저자임, lazy와는 별개임
- 그래도 lazy 저자는 자기만의 방식으로 양질의 인터페이스를 잘 만들어내는 역량이 있다고 봄, 나는 그 방식이 꽤 마음에 들어서 자주 최고라고 생각하게 됨. Snacks picker가 대표적으로 최고의 선택지가 됨
나 오래된 vim 유저지만, neovim에서 플러그인 끼고 쓰는 것은 결국 별로라고 판단했음, 뭔가 계속 깨짐. 차라리 핵심 플러그인(LSP, tree sitter)을 네이티브로 통합했으면 neovim이 더 잘 나가겠다고 생각함
- 나도 같은 느낌이었고, C/C++ 개발에는 vim-plug, gutentags(ctags), ALE 쓰면서 잘 버텼음. 근데 web 개발하면서 여러 문법과 툴을 써야 해서 결국 neovim 디스트로로 갈아탐. 여러 배포판을 써봤는데 (이제는 중단된) Lunarvim과 현재는 Astronvim이 잘 맞았음
- 사실 tree-sitter와 LSP는 이미 네이티브 통합되어 있음, 주요 LSP/tree-sitter 플러그인은 기본 설정 및 쿼리 번들만 제공하고, 향후 nvim-treesitter에 의존하지 않도록 쿼리 자체를 neovim이 네이티브로 번들링할 계획도 있음. LSP 설정도 매우 쉬워졌고, 예를 들면
```
vim.lsp.config("expert", {
  cmd = { "expert" },
  root_markers = { "mix.exs", ".git" },
  filetypes = { "elixir", "eelixir", "heex" },
})
vim.lsp.enable("expert")
```
  그리고 "LspAttach" autocmd에서 LSP 별 keymap 설정도 가능함
- 내 생각엔 앞으로 5~10년 안에는 정리가 되지 않을까 하는 예측임
꽤 오랫동안 사용중인데 아무런 문제 없음 내 dotfiles 참고
솔직히 꼭 미니멀할 필요도 없고, 다른 특수한 이유만 없으면 통합 솔루션이 되었으면 함. 현재는 vim pack과 git submodule을 병용하는데, 어떤 GitHub 프로젝트가 최적/추천/지원이 잘 되는지 혼란스러워서 nvim 패키지 매니저를 또 고르고 싶지가 않음
이게 추가된 오리지널 이슈임 neovim 공식 이슈 #20893, 네오빔 프로젝트에서 오래된 목표였던 듯 하나, 왜 그런지 설명은 없었음. 솔직히 기존 플러그인들이 이미 훌륭한 역할을 해왔으니 군더더기(bloat) 같다는 느낌이었음. 하지만 일부는 동의하지 않은 듯함
- 그 이슈 안에 설명이 포함되어 있으니 참고하길 바람 해당 이슈의 설명

답변달기