Skip to content
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

Post install hook issue #83

Closed
SanchayanMaity opened this issue Nov 3, 2020 · 8 comments
Closed

Post install hook issue #83

SanchayanMaity opened this issue Nov 3, 2020 · 8 comments

Comments

@SanchayanMaity
Copy link

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
Copy link
Contributor

nanotee commented Nov 4, 2020

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
Copy link
Owner

wbthomason commented Nov 5, 2020

@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
Copy link
Author

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

Closing the issue.

@ilAYAli
Copy link

ilAYAli commented Jan 19, 2021

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 <akin.sowemimo@gmail.com>
Date:   Sat Jan 16 21:20:35 2021

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

@wbthomason
Copy link
Owner

@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

plugin_utils.list_installed_plugins = function()

and the tag_oldest definition is now

local txt_newest = math.max(unpack(txt_ftimes))
local tag_oldest = math.min(unpack(tag_ftimes))

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
Copy link

ilAYAli commented Jan 19, 2021

@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
Copy link
Owner

Great, glad it's working now!

@ilAYAli
Copy link

ilAYAli commented Jan 19, 2021

Good job, and nice progress with luarocks btw!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants