Packer.nvim: No change detected when altering plugin URI from upstream repo to local path

[Iron-E]

Hello,

Thanks again for your continued work on this project. I've been enjoying using it lately!

There seems to be an issue when changing between local projects and upstream URLs. For example:

1. Specify an upstream plugin.
   lua return require('packer').startup{function(use) use {'rust-lang/rust.vim', opt=true} end}
2. Install the upstream plugin.
   sh nvim +PackerCompile +PackerSync
3. Re-specify the plugin to use a local path.
   lua return require('packer').startup{function(use) use {fn.glob('~/Programming/ACTIVE/rust.vim'), opt=true} end}
4. Install the local plugin.
   sh nvim +PackerCompile +PackerSync

The second PackerSync will report "already clean" and won't replace the currently downloaded plugin with a symlink to the directory specified.

[wbthomason]

Thanks for the report! Yep, this is something I admit I've never tried, and the code does not handle. The check for missing plugins just looks to see that there's a name in the right place, and so everything seems correct to packer in this instance.

I suppose the right thing to do would be to also validate installed plugin types (e.g. look for the plugin being a symlink if it's local, look for a .git dir if it's a git plugin) and perform a remove and install if it's not right.

[Iron-E]

I see there's a method for checking plugin types in the utilities. Is update_plugin the right place for such a check? Or would it go in find_missing_plugins?

Want to verify I understand the structure before any work is done.

[akinsho]

Just noting that I think this is also the case for when the branch is changed. In this case, I believe specifying a branch should be picked up and the repo switched over as well. It seems the current behaviour is that you have to manually remove the plugin and reinstall it

[akinsho]

Moving over some of what I mentioned in #137 here since it all largely comes back to this issue.
TLDR: I'm trying to specify local and upstream plugins in two branches of a conditional i.e.

if condition then
 use {"remote/plugin"}
else
 use {"~/local/plugin"}
end

switching the variable doesn't cause the new branch to be picked up since they are both identified as the same plugin so no change should be made.

I followed @Iron-E's suggestion of using an alias via use {"~/my-plug", as = "local-my-plug"} and though the name is changed in the plugin directory PackerInstall and PackerUpdate don't register them as different

[Iron-E]

In that snippet, condition will only be checked on each :PackerCompile. This is because the plugin specification is only compiled when running that command (afaik).

Does it work if you specify both at the same time, and use cond to specify condition? That should allow :PackerCompile to detect both at once, but conditionally load either depending.

Something like this:

local function foo_condition()
    return condition
end

use {'~/local/foo', as='local-foo', cond=foo_condition}
use {'remote/foo', cond=function() return not foo_condition() end}

If as doesn't make the plugins register as different in this case, we can open another issue since it should probably be doing that.

[akinsho]

@Iron-E I've just tried it out and it doesn't work. I've had a look through the code and can see how it's happening now. Both the local and remote plugin get registered as foo since the path isn't used to make the plugin's name unique e.g. my-username/foo. As for using the as key this is actually not checked till after the plugin name check so the above error fails with foo has already been added.

  -- lua/packer.lua
  local path = vim.fn.expand(plugin[1])
  local name_segments = vim.split(path, util.get_separator())

  local segment_idx = #name_segments
  local name = name_segments[segment_idx]
  while name == '' and segment_idx > 0 do -- <-- not sure if this logic was intended to make the name unique
    name = name_segments[segment_idx]
    segment_idx = segment_idx - 1
  end
  --- later on
   if plugins[name] then
    log.warning('Plugin \\"' .. name .. '\\" is used twice!')
    return
  end