Allow vim-plug to be managed as a plugin

[jwhitley]

This trivial change allows vim-plug to manage itself, as was commonly possible with Vundle. Using my vim setup as an example:

From .vim/bootstrap/bundles.vim:

let s:bundle_home=Dot_vim("bundle")
let s:plug_tool_home=Dot_vim("bundle/vim-plug")

if !isdirectory(Dot_vim("bundle/vim-plug/.git"))
  silent exec "!mkdir -p ".s:bundle_home
  silent exec "!git clone https://github.com/jwhitley/vim-plug.git ".s:plug_tool_home
  let s:bootstrap=1
endif

exec "set rtp+=".s:plug_tool_home
call plug#begin(s:bundle_home)

" let vim-plug manage vim-plug
Plug       'jwhitley/vim-plug'

" Lots of other plugins omitted....

if exists("s:bootstrap") && s:bootstrap
  unlet s:bootstrap
  autocmd VimEnter * PlugInstall
endif

call plug#end()

With plug.vim moved to autoload/plug.vim, it's possible to point rtp at a clone of vim-plug, then load it up via call plug#begin(...). Since it's a clone, git can easily manage it and therefore vim-plug can easily self-update.

The rest of the code above is just my own bootstrapping system, included for completeness, which installs the plugin manager (now, vim-plug) and calls :PlugInstall if this is the initial run on this system.

[vheon]

Have you already read #69?

[jwhitley]

Sigh, nope, I missed that @vheon. Terribly obvious in hindsight, should have looked harder. Thanks. Closing.

FWIW, I do disagree with the logic in #69. It is far more of a hassle for me to have to pull updates to vim-plug manually. The reason is that every single time I want to do an update to vim-plug, I have to go through the manual process again ("what's that curl invocation again?") and have no easy way to reference what changes I'm pulling. Downloading vim-plug as a clone is far easier (one command, simpler URLs, or no URLs if you use hub), and vim-plug provides a wonderful UI for letting me know what updates I just pulled.

[jwhitley]

Final addendum for posterity: I just modified my fork to use a symlink autoload/plug.vim -> ../plug.vim which maintains backwards compatibility and avoids git getting stupid about merging across a rename, while achieving the same result as I describe above.

[vheon]

The reason is that every single time I want to do an update to vim-plug, I have to go through the manual process again ("what's that curl invocation again?") and have no easy way to reference what changes I'm pulling

What is wrong with :PlugUpgrade?

for the bootstrap taken directly from the implementation of :PlugUpgrade

hub clone --depth 1 junegunn/vim-plug tmp
mkdir -p ~/.vim/autoload && cp tmp/plug.vim ~/.vim/autoload/plug.vim

Downloading vim-plug as a clone is far easier (one command, simpler URLs, or no URLs if you use hub), and vim-plug provides a wonderful UI for letting me know what updates I just pulled.

after :PlugUpgrade vim-plug create a plug.vim.old file inside the autoload directory so you can

vimdiff ~/.vim/autoload/plug.vim ~/.vim/autoload/plug.vim.old

[jwhitley]

@vheon, thanks for the discussion.

First, I version control my homedir repos. There are some dependencies that are delegated to another system such as a platform package manager (apt, homebrew, etc.), vim plugin manager, etc.

With vim-plug's current approach, whenever vim-plug is updated I need to add, commit, and push that change into my vimrc repo. It becomes a dependency I have to manage, not something delegated to an external package management system.

Second, by not having vim-plug self-update, I no longer get a nice summary of changes. For managed plugins it's trivial to investigate change details via git or GitHub's UI, including browsing associated commits, PRs etc. But with vim-plug's approach I now have to manually peruse the entire diff, with all of the context thrown away. I find that to be a worse UI by a large margin.

Post-Vundle plugin managers, vim-plug included, have done a nice job of building a UI around summarizing changes in VCS-managed plugins. I can't imagine why I would want to dodge that, just to maybe avoid a few lines in my vimrc.

The shallow clone is a fine idea, tho. Adopting that right now. 👍

[junegunn]

The idea of X managing X can be familiar to long-time Vundle users, but it's really not a very straightforward idea. (Just to be clear, I used Vundle before I started vim-plug and the decision not to follow the way of its predecessor was not accidental but intentional)

Consider you are a Vim user who hasn't used a plugin manager (manually putting stuff into ~/.vim) and does not know the Vim's way of managing its "runtime path". Now the problem is two-fold.

1. Manual tinkering of &rtp. This is implementation detail. What is &rtp and why do I have to care? I strongly believe that it's the responsibility of vim-plug to hide such details and allow you to keep your configuration neat and tidy.
2. Having to specify vim-plug itself between begin() and end(). Or vim-plug will remove itself on PlugClean. This is another implementation detail that has caused so many issue reports on Vundle repository and it can be very confusing to the users who don't know/do not want to know the details. "Didn't I already add vim-plug with that rtp thing?" "vim-plug works great and I don't want to update it everytime I update the other plugins. ... Boom!" I'm not aware of any other plugin/package manager (except for vundle) that kills itself on misconfiguration. It's plain wrong.

And you really don't need to update vim-plug frequently. The core feature set is hardly changed these days and most updates are minor fixes for non-conventional environments. If it works for you, you can just forget about it.

[vyp]

-1

I know time is money, but you could always write a script to automate the vim-plug part too right? (By using git clone + symlink obviously.)

[junegunn]

One can argue that it's still possible that we restructure the directory and not tell the users to set up vim-plug like vundle. But see here:
https://github.com/search?q=https%3A%2F%2Fraw.luolix.top%2Fjunegunn%2Fvim-plug%2Fmaster%2Fplug.vim&type=Code&utf8=%E2%9C%93

[vyp]

(@jwhitley) I know your point was you want it to be managed by a package manager of some sort, but as long as you automate updating vim-plug, I think it's fine because vim-plug is relatively stable now as junegunn says.

[jwhitley]

@vyp, I get where you're coming from, but I see custom automation as a worse solution than what I did: fork vim-plug and add a symlink from /autoload/plug.vim to /plug.vim. To @junegunn's comment, I think he's right, the ship has sailed on landing a change that moves plug.vim.

If it were desired as a power-user feature, a symlink could be added as I've done. The symlink would not work on Windows without taking special measures, but they could still use the current method of installing and upgrading vim-plug.

[vyp]

fork vim-plug and add a symlink from /autoload/plug.vim to /plug.vim

You still have to update that fork right (pull in updates from this repo), so I meant automating that part? Because while it's still technically "manual" (i.e. does not use a package manager), at least it's automated. Of course, if you already got that covered then don't worry.

Not disputing symlinking, it's what I do too.

[docwhat]

I agree that requiring Plug 'junegunn/vim-plug' isn't a good idea.

But how about running PlugUpgrade (update vim-plug) prior to running PlugUpdate (update plugins)? It will not add any noticeable time if someone has more than 4-5 plugins.

FYI: I found my way here via the FAQ. Why does it suggest running PlugUpdate before PlugUpgrade I haven't had luck with that when a plugin depends on a new vim-plug feature or neovim breaks vim-plug.