Notify about available plugin updates and vim-plug upgrade

[martin-svk]

Hi,

everyday when I start vim I firstly do :PlugUpgrade and then :PlugUpdate and usually no updates are available. If this plugin could provide an interface for statusline or use some other method (e.g. echo message) to display info (at least count) about plugins which have available updates, that would be great.

Something like 4 updates available and plug upgrade available or with less text and with use of some nice symbols. I guess this should be possible using git.

Thanks.

---

• Type:
  • [ ] Bug
  • [x] Enhancement
  • [x] Feature Request
  • [ ] Question
• OS:
  • [x] All/Other
  • [ ] Linux
  • [ ] OS X
  • [ ] Windows
• Vim:
  • [x] Terminal Vim
  • [x] GVim
  • [x] Neovim

[junegunn]

There is no way to know if the remote repository has been updated without contacting it. So in order to print the suggested message (x updates available), vim-plug has to fetch all the changes, which is effectively, :PlugUpdate.

[mike-zueff]

@junegunn, there can be a hack solution for at least git-located VIM plug-ins. So vim-plug can execute something like git ls-remote origin --heads refs/heads/master once a week in order to compare that hash with the one from local .../.git/refs/heads/master for each plug-in. If the values differ then vim-plug can open a new VIM buffer with the news and the update prompt. Do you have a long-term roadmap for this feature implementation?

[mike-zueff]

It would be good to get it implemented for at least automatic vim-plug self-upgrade. Some of the users do :PlugUpdate several times a month but they usually forget to run :PlugUpgrade.

[martin-svk]

@junegunn I actually did a quick how to check for git remote updates google search and the result's looked promising so I tought this is possible. Also @mike-zueff has a good approach for this.

@mike-zueff Is there a reason why the hash compare should be done only once per week? This could be maybe configurable.

[Celti]

Dudes. Just set up a crontab for vim +PlugUpgrade +PlugUpdate +qa! and run the updates as often as you like, automatically.

[mike-zueff]

@martin-svk, of course, it should be configurable.

@Celti, not a good idea, IMHO. Rationale: some plug-ins can take too long time for update. E.g., YouCompleteMe update usually triggers install.py launch and can work for about 15 minutes before the update is completed. So if the computer will be rebooted until the cron job is finished then you can get a buggy plug-in or not completely compiled one. One more argument consists in that it would be nice to control the update process ourselves and view the update summary data in the vim-plug VIM buffer when all the update jobs are completed. The silent update using cron/anacron won't show you the summary actually.

[mike-zueff]

@Celti, also cron/anacron job can be launched when you'll be busy with the software development, etc. So some plug-ins may become broken after automatic update is finished or during the update process workflow. It can be much more comfortable to update all the plug-ins in the spare time or at the end of a working day nevertheless.

[Celti]

Have you ever worried about your computer rebooting in the middle of any other cronjob it comes with? Most Linux distros come with a number enabled by default. But if it's really a problem, have the cronjob inhibit shutdowns while it's running (c.f. molly-guard, polkit inhibitors).

The typical user of Plug, from everything I've seen, simply runs PlugUpgrade and PlugUpdate without any interactivity whatsoever, then (sometimes) reviews the buffer when done. So, dump the buffer to stdout when you're done (or simply run Vim in 'exim' mode for the job) so that cron emails you the output.

As for updates happening while you're busy with software development... you could have the cron job check for running Vim sessions and inhibit itself, but I don't think that's actually a problem — once Vim is loaded, a plugin is not going to reload itself from disk unless you tell it to, therefore changing the plugin on the disk isn't going to affect your development session one iota.

None of those problems are insurmountable, or even terribly difficult to solve — but they do require you to do something.

[martin-svk]

@Celti None of those problems are insurmountable, or even terribly difficult to solve — but they do require you to do something.

That's true. But isn't it easier to find a good way for my proposed feature to work? It's not much harder to solve and no user has to do anything like cron + molly-guard + etc. fancy stuff. I mean, almost every modern editor now displays a notification when plugin updates are available.

[junegunn]

vim-plug labels itself as "minimalist plugin manager" and I'm not in favor of adding more features to it. Unlike "modern" editors, Vim is basically a single-threaded, synchronous program, and to start a background process, you'll have to use a bleeding-edge version of Vim or Neovim, while one of the strong points of vim-plug is its obsession with backward compatibility (almost all of its features work in archaic Vim 7.0 with Git 1.7)

What I'd like to stress is that, you can implement the idea as an external script, like an addon plugin. Since vim-plug exposes its data structure via g:plugs variable, you can refer to it. Or to make things simpler, you can blindly check the directories in ~/.vim/plugged in a shell script that is registered as a cron job, and display the result of it on your statusline.

If you come up with a solution, let me know. We can put it on the wiki, or if it turns out to be really nice and simple, we can then consider integrating it to the project in some way.

[kiryph]

@junegunn Would you reconsider this issue in 2018?

vim8 is now the default version on current

• macOS 10.13
• Debian 9
• Ubuntu (since 17.04)
• Fedora

Some of the more conservative Linux distributions (such as Mint or openSuse) are still on 7.4 but this will certainly change and does not really count as an argument against it. People on rolling release Linux distributions have most likely already a newer vim version (otherwise it does not make sense to use a rolling release).

Many user could already use it today and more are about to come. Your plugin is certainly one of the most popular vim plugin manager.

And most importantly: this issue is also about a feature which people have to add manually to their configuration of the statusline. It does not hurt anybody with an older vim version as long as they do not add it. It is easy to document the requirements and even give a meaningful message in vim why it does not work if someone tries nevertheless (e.g. uses a central configuration on several machines).

I am interested in a self-contained solution to see the number of packages where git tells you that changes are available. Crontab is an external tool which is also not available on all platforms (e.g. Windows). This would also require additional vim setup to query the output of the cronjob to add its results to the statusline. It would make more sense if vim8 checks itself and then redraws the statusline. When I do not use vim, there is also no need for the cronjob.

Vim8 has now the timer and job feature which should provide all functionality required.

IMHO, even from a technical standpoint it would make sense to add this to a vim plugin itself.

I understand your reasoning about a minimalistic plugin manager. I think vim-plug is a great plugin manager with many good features and see no reason why a return string for the statusline goes beyond what this plugin manager does. I do not want to have a second plugin for showing plugin updates in the statusline and honestly see no reason for this.

It also fits into the scheme of many plugins which provide strings for the statusline (fugitive#statusline(), SleuthIndicator(), tagbar#currenttag(), gutentag#statusline(), GitgutterGetHunkSummary(), ale#statusline#Status(), ObsessionStatus(), virtualenv#statusline(), ...).

Why not add a useful thing which frees everybody from stupid tasks such as to check whether updates are available?

[sersorrel]

@kiryph It's worth noting that Ubuntu 16.04 is still on Vim 7.4, and is supported until 2021. There is not even an LTS Ubuntu release with Vim 8 yet!

[kiryph]

@anowlcalledjosh Sorry to nit-pick: I have mentioned that vim8 is only available for Ubuntu 17.04 or newer and also tried to elaborate why arguments as yours do not really motivate to wait till everybody has vim8. For instance, people on server distros with official support for a decade will not have vim8 for a long time even after 2021. The point is that there is already a significant amount of users who can use it, not everybody, but also not a tiny group.

Since junegunn himself did not respond, any discussions are also most likely irrelevant. Regardless of your opinion whether it is a useful feature or not.

[kiryph]

There is not even an LTS Ubuntu release with Vim 8 yet!

The next Ubuntu LTS release will be available in a month. Do you really think this is a reason not to implement this? (https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule) The next time someone checks this thread a month has passed. Sorry, I really can't understand you here!

[semanser]

Thanks to g:plugs variable I have created a very simple plugin that shows the number of outdated plugins: vim-outdated-plugins. It works with both Vim and Neovim.

[kiryph]

@semanser: Thanks for creating this plugin!

Right now I still use vim and would love to hear about vim support. Why did you attach the label invalid to your issue https://github.com/semanser/vim-outdated-plugins/issues/1.

My vim instances are often running several days. Would you mind adding an option to trigger a check after a certain period of time, not only on VimEnter.

[semanser]

@kiryph Thanks, I replaced the invalid label :)

Vim support will be added when I will found a time to do that, but probably in a few days, I think.

This plugin exports CheckForUpdates() function and you can bind it to some shortcut and runs it manually. But the idea with a timer is also good.

[semanser]

@kiryph I have added both Vim and Neovim support in https://github.com/semanser/vim-outdated-plugins/commit/003bf9d11e1cd4ad75c2ad09abdd8a14c7f85b5f so now you can test it :)

[kiryph]

@Semanser Thanks for the quick addition. I will definitely give you feedback this week.

I had a look into the file https://github.com/semanser/vim-outdated-plugins/blob/master/plugin/vim-outdated-plugins.vim:

Single job control api for vim and neovim

I think https://github.com/prabirshrestha/async.vim could remove the need to code everything twice. Note that https://github.com/k-takata/minpac uses also async.vim by prabirshrestha to support vim and neovim. For convenience k-takata has copied the file https://github.com/prabirshrestha/async.vim/blob/master/autoload/async/job.vim into the repository of minpac https://github.com/k-takata/minpac/blob/master/autoload/minpac/job.vim to make minpac self-contained.

[semanser]

@kiryph Thanks for the suggestion. Yes, I find ugly to separate basically the same logic twice, just to be compatible with Vim and Neovim. I will dive deeper into Async.vim plugin, thanks.

[junegunn]

@semanser Cool plugin, thanks for sharing!