Git repository google/yapf puts its Vim plugin in a subdir plugins/vim. The idiomatic way of specifying this subdir in Packer is using its rtp option. It doesn't work because Packer is changing rtp too late. The change happens when Vim starts loading plugins because Packer itself is a plugin. For the new rtp to work, the change must happen before Vim starts loading plugins. For example, in init.vim. But the current way Packer works is not in accordance with this solution, because we probably don't want to source entire packer_compiled.lua in init.vim. And it doesn't fully address the problem below.
Furthermore, there is another problem with Packer as it is. When specify a Git repository as a Packer package, Packer would checkout the repository at a path that Vim uses for a package, even if the actual Vim package in that repository is located in a subdir. In the example of google/yapf, the root of it is put at Vim package path, not google/yapf/plugins/vim. In other words Packer puts something that is not a Vim package at Vim package path. Even though this does not look harmful in this case, it can wreak havoc if google/yapf has plugin dir containing Vim files at its root. The way to avoid this is to checkout Git repositories somewhere else and make symlinks at Vim package paths like Packer does right now for local repositories. On Linux systems ~/.local/share/packer or ~/.local/share/nvim/packer seem to be good candidates. Currently to fix the problem, we can do the symlink manually, but this should really be unnecessary and fixed in Packer itself.
Steps to reproduce
Install
yapfusing Packer:Run
PackerSync.Restart and run command
YAPF.Actual behaviour
Command
YAPFis not found.Expected behaviour
Command
YAPFis found.Detailed Explanation
Git repository
google/yapfputs its Vim plugin in a subdirplugins/vim. The idiomatic way of specifying this subdir in Packer is using itsrtpoption. It doesn't work because Packer is changingrtptoo late. The change happens when Vim starts loading plugins because Packer itself is a plugin. For the newrtpto work, the change must happen before Vim starts loading plugins. For example, ininit.vim. But the current way Packer works is not in accordance with this solution, because we probably don't want to source entirepacker_compiled.luaininit.vim. And it doesn't fully address the problem below.Furthermore, there is another problem with Packer as it is. When specify a Git repository as a Packer package, Packer would checkout the repository at a path that Vim uses for a package, even if the actual Vim package in that repository is located in a subdir. In the example of
google/yapf, the root of it is put at Vim package path, notgoogle/yapf/plugins/vim. In other words Packer puts something that is not a Vim package at Vim package path. Even though this does not look harmful in this case, it can wreak havoc ifgoogle/yapfhasplugindir containing Vim files at its root. The way to avoid this is to checkout Git repositories somewhere else and make symlinks at Vim package paths like Packer does right now for local repositories. On Linux systems~/.local/share/packeror~/.local/share/nvim/packerseem to be good candidates. Currently to fix the problem, we can do the symlink manually, but this should really be unnecessary and fixed in Packer itself.