Packer.nvim: Post install hook issue

[SanchayanMaity]

First of all, thank you for your work on this plugin. Am quite liking it's UX so to speak.

Neovim version: NVIM v0.5.0-789-gca7449db4

Currently, trying to use the post install hook does not seem to work for plugins like fzf which use funcrefs. In fzf, the post install hook is fzf#install. Having this in packer's post install hook for the fzf plugin,

function() 
    vim.fn['fzf#install']()
end

does not work.

I do not see an error as such for this. The expected behavior is that even if on host distribution, fzf is not installed or up to date or available in path, the above hook takes care of making the latest binary available without necessarily installing it globally. With vim-plug, even if my host fzf binary is not up to date which is what latest fzf.vim requires, the hook takes care of the issue.

Even if vim funcrefs are a problem, I was thinking ./install --all would work. But, that does not seem to be the case either. It does not create a ~/.fzf which is what the install script in fzf would do, if it was run manually. I do not have any other plugins requiring post install hook, so not sure if the issue is for some idiosyncrasy of fzf or an issue in packer.

For now, I bypass the issue in my case, by manually putting the latest fzf binary in ~/.local/bin.

[nanotee]

I was able to reproduce this. I got this error message:

[packer] Error in coroutine: ...ack/packer/start/packer.nvim/lua/packer/plugin_utils.lua:124: bad argument #1 to 'pcall' (value expected)

I changed line 124 in plugin_utils.lua from this:

        if pcall(plugin.run(plugin)) then

to this:

        if pcall(plugin.run, plugin) then

And it seemed to fix the problem

[wbthomason]

@nanotee Thanks, nice catch! Interestingly, when I tried to repro this, I was getting a different error.

I've pushed 6f9efb2 adding your fix to plugin_utils. @SanchayanMaity could you confirm that this fixes your issue?

Thank you!

[SanchayanMaity]

Yes, this seems fixed now. Thank you very much @nanotee and @wbthomason .

Closing the issue.

[ilAYAli]

I am still getting this related error:

plugin_utils.lua:49: bad argument #1 to 'min' (number expected, got no value)

plugin_utils.lua:49:
local tag_oldest = math.min(unpack(util.map(vim.fn.getftime, tags)))

```
commit 30313aaa1c698ee3a5116041df5c3555aaae990e (HEAD -> master, origin/master, origin/HEAD)
Author: Akin [e-mail]
Date: Sat Jan 16 21:20:35 2021

fix: only try and remove installed disabled plugins (#163)

[wbthomason]

@ilAYAli: Thanks for your report! I'm a little confused by the state of your packer repo - the commit you posted is in fact the latest commit on master, but the line you post from plugin_utils.lua is not the current state.

That line is currently https://github.com/wbthomason/packer.nvim/blob/30313aaa1c698ee3a5116041df5c3555aaae990e/lua/packer/plugin_utils.lua#L49

and the tag_oldest definition is now https://github.com/wbthomason/packer.nvim/blob/30313aaa1c698ee3a5116041df5c3555aaae990e/lua/packer/plugin_utils.lua#L73-L74

Could you please make sure that (1) your packer repo is up to date on master and (2) you only have one copy of packer (I have seen issues similar to this when someone initially cloned packer into one location, but did not use the same location as their package install_root, causing packer to download another copy of itself into the install_root)?

[ilAYAli]

@wbthomason you are absolutely correct. It seems that I had a combination of repos, both in .config/nvim/lua/packer and ~/.local/share/nvim/site/pack/packer/opt/packer.nvim
Removing the former solved the issue.
Thank you for looking into this.

[wbthomason]

Great, glad it's working now!

[ilAYAli]

Good job, and nice progress with luarocks btw!