New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notify about available plugin updates and vim-plug upgrade #493

Closed
martin-svk opened this Issue Jun 14, 2016 · 21 comments

Comments

Projects
None yet
7 participants
@martin-svk

martin-svk commented Jun 14, 2016

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
    • Enhancement
    • Feature Request
    • Question
  • OS:
    • All/Other
    • Linux
    • OS X
    • Windows
  • Vim:
    • Terminal Vim
    • GVim
    • Neovim
@junegunn

This comment has been minimized.

Show comment
Hide comment
@junegunn

junegunn Jun 15, 2016

Owner

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.

Owner

junegunn commented Jun 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mike-zueff

mike-zueff Jun 15, 2016

@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 commented Jun 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mike-zueff

mike-zueff Jun 15, 2016

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.

mike-zueff commented Jun 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@martin-svk

martin-svk Jun 15, 2016

@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.

martin-svk commented Jun 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Celti

Celti Jun 15, 2016

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

Celti commented Jun 15, 2016

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

@mike-zueff

This comment has been minimized.

Show comment
Hide comment
@mike-zueff

mike-zueff Jun 15, 2016

@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 commented Jun 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mike-zueff

mike-zueff Jun 15, 2016

@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.

mike-zueff commented Jun 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Celti

Celti Jun 15, 2016

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.

Celti commented Jun 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@martin-svk

martin-svk Jun 16, 2016

@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.

updates_available

martin-svk commented Jun 16, 2016

@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.

updates_available

@junegunn

This comment has been minimized.

Show comment
Hide comment
@junegunn

junegunn Jun 16, 2016

Owner

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.

Owner

junegunn commented Jun 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kiryph

kiryph Mar 10, 2018

@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?

kiryph commented Mar 10, 2018

@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?

@anowlcalledjosh

This comment has been minimized.

Show comment
Hide comment
@anowlcalledjosh

anowlcalledjosh Mar 22, 2018

@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!

anowlcalledjosh commented Mar 22, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@kiryph

kiryph Mar 22, 2018

@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 commented Mar 22, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@kiryph

kiryph Mar 22, 2018

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!

kiryph commented Mar 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@semanser

semanser Apr 1, 2018

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.

semanser commented Apr 1, 2018

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

This comment has been minimized.

Show comment
Hide comment
@kiryph

kiryph Apr 2, 2018

@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 semanser/vim-outdated-plugins#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.

kiryph commented Apr 2, 2018

@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 semanser/vim-outdated-plugins#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

This comment has been minimized.

Show comment
Hide comment
@semanser

semanser Apr 2, 2018

@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 commented Apr 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@semanser

semanser Apr 2, 2018

@kiryph
I have added both Vim and Neovim support in semanser/vim-outdated-plugins@003bf9d so now you can test it :)

semanser commented Apr 2, 2018

@kiryph
I have added both Vim and Neovim support in semanser/vim-outdated-plugins@003bf9d so now you can test it :)

@kiryph

This comment has been minimized.

Show comment
Hide comment
@kiryph

kiryph Apr 2, 2018

@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.

kiryph commented Apr 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@semanser

semanser Apr 2, 2018

@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.

semanser commented Apr 2, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@junegunn

junegunn Apr 3, 2018

Owner

@semanser Cool plugin, thanks for sharing!

Owner

junegunn commented Apr 3, 2018

@semanser Cool plugin, thanks for sharing!

@junegunn junegunn closed this Apr 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment