Symlink Git repository at Vim package path

[tae-soo-kim]

Steps to reproduce

1. Install yapf using Packer:

   use({
       "google/yapf",
       branch = "main",
       rtp = "plugins/vim",
   })
   

2. Run PackerSync.

3. Restart and run command YAPF.

Actual behaviour

Command YAPF is not found.

Expected behaviour

Command YAPF is found.

Detailed Explanation

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.