Let vim-plug manage itself

[yous]

I used Vundle.vim and liked the way of they manages itself. I wondered if vim-plug is possible too, so I cloned vim-plug into ~/.vim/plugged/vim-plug and tested with my .vimrc:

set runtimepath=~/.vim/plugged/vim-plug
call plug#begin('~/.vim/plugged')
" Let vim-plug manage itself
Plug 'junegunn/vim-plug'
" Many plugs...
call plug#end()

Note that plug.vim is in root directory of vim-plug, so I moved it to vim-plug/autoload/plug.vim and it works flawlessly.

When this is done, PlugUpdate does PlugUpgrade too so it can be removed. But I think it can make some compatibility issue for pre-installed users.

[vheon]

I personally don't like this much: the set runtimepath ... thing is just noise (and I've used Vundle, NeoBundle, and pathogen before vim-plug so I know that every one do it like this except pathogen) and usually you do not upgrade vim-plug that often to justify the self management, always IMHO. Plus using it this way means that when I have to bootstrap my vim config I have to clone the vim-plug repo and then PlugInstall for installing all the plugins, instead I just commit the plug.vim inside my vim config. Just my use case so any discussion I more than welcome.

A comment on your example though:

set runtimepath=~/.vim/plugged/vim-plug be careful, I don't know if it was a typo but use += since using just = you're throwing away your current runtimepath and replacing it with ~/.vim/plugged/vim-plug so it will became the first directory in your runtimepath. The first directory is used by vim for saving some kind of file like the dict.

[junegunn]

@vheon put it very nicely. One of the primary motivations behind vim-plug is the ease of setup. I deliberately designed it to be in a single file so that it can be easily downloaded and put into ~/.vim/autoload so no manual modification of runtimepath is required. Yeah, it's just a single line, but since the role of vim-plug, or any other vim plugin managers, is the automatic management of runtimepath, I really didn't like that specific boilerplate code. I want the users of vim-plug to be completely oblivious of the existence of runtimepath option.

I've noticed the pattern that the users of pathogen and vim-plug include the plugin manger file in their dotfiles repo (like @vheon does), which reduces a step in setting up their environment. And I encourage this practice. In fact the decision to not put plug.vim file inside autoload directory was made partly to discourage the "Vundle way" of managing it.

PlugUpgrade may seem redundant but one of the benefits of having a separate PlugUpgrade command is that it allows me to execute some extra code to upgrade the internals of vim-plug and reload it so that it just works without a restart.

And lastly as @vheon mentioned, you probably won't need to upgrade vim-plug until you notice something's broken, especially at this point where I don't expect to introduce substantial changes to vim-plug itself.

I hope this comment helps you understand the ideas behind the decisions that have made vim-plug the way it looks now. I'm closing this issue. Thanks for the suggestion!

[yous]

@vheon Oh right, I missed + before = on set runtimepath.

I understood what you said and I agreed. I'll just put plug.vim to ~/.vim/autoload/plug.vim: yous/dotfiles@aeea7a0.

But I still think it'll be good if plug.vim moves to autoload/plug.vim. Maybe this convention is for the compatibility for pathogen or Vundle.vim, but I think it makes the project to be more self-descriptive.

[junegunn]

Okay, well in my case I have plug.vim downloaded by the installer script.

There are some tricky issues in relocating the file.

1. I mentioned in the earlier comment that I intentionally didn't put plug.vim in autoload directory. Cloning it has not been the recommended way of using it.
2. Because of the reasoning, I once put large GIF files in the repo. I regret it now and they're removed, but they're still taking the same amount of space because git remembers the entire history. You'll notice this repository is quite large when cloned, above 8MB. This makes me hesitate even more to recommend cloning it. We may rewrite the history and remove those GIF objects, but I guess it will cause huge trouble for those who already have it cloned somewhere (using git submodule or whatever)
3. Like me, there are many people who have plug.vim URL hardcoded in their dotfiles installer script. So simply moving it to autoload directory is not an option now. As we don't like to just have two identical copies of the file in the repo, we might consider using a symlink, but I'm not sure if it works as expected on Windows.

[yous]

Oh, I understand. Relocating plug.vim has no benefits, also causes compatibility issues. Thanks for quick responses!