Packer.nvim: Dependancies not cleaning after moving from github dep to local dep.

Created on 18 Dec 2020  路  4Comments  路  Source: wbthomason/packer.nvim

Course of events:

  • Setup a dependancy: use {"tjdevries/colorbuddy.nvim"}
  • :PackerInstall, :PackerCompile

Now I want to make a local version using the the same colorbuddy.nvim.

    -- use {"tjdevries/colorbuddy.nvim"}
    use {"~/code/colorbuddy.nvim", branch = "master"}

Save nvim/lua/plugins.lua with the update above.

  • :PackerSync, :PackerCompile

Check my code and no changes to the dependancies.

  • :PackerClean, :PackerUpdate, :PackerInstall, :PackerCompile

Still no updates to the dependancies.

  • Figure out where the packer files are stored. They are not where documented in the example or anywhere in the documentation.
  • https://github.com/wbthomason/packer.nvim/issues/117 Tells me of a new folder
  • Go into the folder
  • ~/.config/local/share/nvim/site/pack/colorbuddy.nvim is STILL the github dependancy.
  • Manually remove the colorbuddy.nvim folder
  • Go back into nvim
  • :PackerInstall
  • Says new dependency is installed ~/code/colorbuddy.nvim

I think it should do better checks for local directories and properly remove dependancies that are no longer referenced from github.

  • Update use {"tjdevries/colorbuddy.nvim"} to use {"~/code/colorbuddy.nvim", branch = "master"}
  • :PackerUpdate - maybe this should remove the dependancy
  • :PackerClean - should remove the dependancy
  • :PackerInstall - should note conflicting dependancy or that it changed.
bug enhancement help wanted

Most helpful comment

This is related to #118; basically, packer only checks the names of installed plugins, and not whether they're the right "type" (i.e. a symlink or a directory with a .git repo), so it currently has no way to detect that it needs to change. Fixing #118 should fix this issue.

As a note, the install location is documented: it's package_root as shown in the table of default config variable values in https://github.com/wbthomason/packer.nvim#custom-initialization.

Your use brings up an issue I admit I hadn't thought of - you're trying to use a branch with a local plugin. packer won't check for that (I assumed that if someone was using a local plugin, then they would've manually checked out the branch they wanted). Perhaps this should be changed.

All 4 comments

This is related to #118; basically, packer only checks the names of installed plugins, and not whether they're the right "type" (i.e. a symlink or a directory with a .git repo), so it currently has no way to detect that it needs to change. Fixing #118 should fix this issue.

As a note, the install location is documented: it's package_root as shown in the table of default config variable values in https://github.com/wbthomason/packer.nvim#custom-initialization.

Your use brings up an issue I admit I hadn't thought of - you're trying to use a branch with a local plugin. packer won't check for that (I assumed that if someone was using a local plugin, then they would've manually checked out the branch they wanted). Perhaps this should be changed.

These sound fair.

In terms of package_root it says

  package_root   = util.is_windows and '~\\AppData\\Local\\nvim-data\\site\\pack' or '~/.local/share/nvim/site/pack'

but its actually

  package_root   = util.is_windows and '~\\AppData\\Local\\nvim-data\\site\\pack' or '~/.config/local/share/nvim/site/pack'

Making it confusing

I do not think I need to set the branch but wanted to see what would happen. I think the local stuff shouldn't be touched as it would just make things confusing.

@rockerBOO: Does #144 address this?

Closing for now because I think #144 should address this; feel free to re-open if I'm wrong.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

clason picture clason  路  5Comments

clason picture clason  路  6Comments

SanchayanMaity picture SanchayanMaity  路  8Comments

clason picture clason  路  4Comments

p00f picture p00f  路  5Comments