search

wbthomason / packer.nvim

A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
MIT License
7.87k stars 267 forks source link

"lock=true" has no effect #643

Closed mcctuxic closed 2 years ago

mcctuxic commented 3 years ago

Steps to reproduce

create a local copy of some plugin. Use "use { ', lock=true }" to reference it. Do a ":PackSync". You will be asked, whether it is ok to remove that plugin

Actual behaviour

You will be asked, whether it is ok to remove that plugin. Documentations says: "lock = boolean, -- Skip this plugin in updates/syncs"... According to that, Packer should not ask, whether to remove that plugin.

Expected behaviour

Packer should not ask to remove plugings, which are set to "lock=true"

packer files

Plugin specification file(s) Post or link your plugin specification files here, if you aren't able to provide a minimal reproducer
packer log file Post the contents of ~/.cache/nvim/packer.nvim.log here
packer compiled file Post the contents of `packer_compiled.vim` here
wbthomason commented 3 years ago

Thanks for your report! I think this could be considered a documentation bug or a code bug - the intent of lock was to prevent a plugin from receiving updates, i.e. freezing it at its current version. It was not to prevent plugins from being cleaned. However, you're right that the docs as written imply that nothing will be done to a locked plugin on update/sync, which is currently not correct.

I'll have to think about how I want to resolve this - can you elaborate on your intended use case for lock, so that I can determine if I'd rather change the behavior or the docs?

mcctuxic commented 3 years ago

On 10/09 01:21, Wil Thomason wrote:

Thanks for your report! I think this could be considered a documentation bug or a code bug - the intent of lock was to prevent a plugin from receiving updates, i.e. freezing it at its current version. It was not to prevent plugins from being cleaned. However, you're right that the docs as written imply that nothing will be done to a locked plugin on update/sync, which is currently not correct.

I'll have to think about how I want to resolve this - can you elaborate on your intended use case for lock, so that I can determine if I'd rather change the behavior or the docs?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/wbthomason/packer.nvim/issues/643#issuecomment-939255017

Hi Wil,

thanks for your superquick reply :) ! I have made a copy of a theme, which was created with color_buddy. This copy is on my harddisk only or in other words...it is not on github. The copy is stored at the same place as any other plugin and it needs color_buddy, which provides the needed functionality. The colorscheme is more or less "color data only". It does not work when installed as normal colorscheme nor is it a colorscheme in n/vims point of view. As path I gave the full path to the colorscheme as described in the docs together with the usual "use { ... }". With this configuration, Packer always wanted to remove this local stored plugin...which is somehow unexpected, since this plugin has its 'use{...}'-case (so to say... :) ). So I added ", lock=true" because I (falsly) thought, that this will make the plugin "invisible" to Packer. The main question for me is: How can I convince Packer not to remove a certain plugin? This becomes even more important, if one is on the way to develop a plugin, which is still not on github. Maybe adding a flag, which directly does, what it says, will do the trick - something like "noremoval=true"?

The current situation is a little annoying especially in those case, where other plugins need to be uninstalled, but my colorscheme should not. In this case I have to remove all plugins and restore the colorscheme from a backup.

shadmansaleh commented 3 years ago

As path I gave the full path to the colorscheme as described in the docs together with the usual "use { ... }". With this configuration, Packer always wanted to remove this local stored plugin...which is somehow unexpected, since this plugin

Is your local plugin in the same dir as plugins installed by packer ?

I think you need to have it in different directory then the packer managed one and provide path to that in use.

for example if your plugin is abc.nvim and packer managed plugin dir is ~/.local/share/nvim/site/pack/packer. don't have it as ~/.local/share/nvim/site/pack/packer/(start|opt)/abc.nvim Instead place it somewhere else like say ~/.config/nvim/my_plugs/abs.nvim and let packer know of that location

use {'~/.config/nvim/my_plugs/abs.nvim'}
mcctuxic commented 3 years ago

On 10/09 06:23, Shadman wrote:

As path I gave the full path to the colorscheme as described in the docs together with the usual "use { ... }". With this configuration, Packer always wanted to remove this local stored plugin...which is somehow unexpected, since this plugin

Is your local plugin in the same dir as plugins installed by packer ?

I think you need to have it in different directory then the packer managed one and provide path to that in use.

for example if your plugin is abc.nvim and packer managed plugin dir is ~/.local/share/nvim/site/pack/packer. don't have it as ~/.local/share/nvim/site/pack/packer/(start|opt)/abc.nvim Instead place it somewhere else like say ~/.config/nvim/my_plugs/abs.nvim and let packer know of that location

use {'~/.config/nvim/my_plugs/abs.nvim'}

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/wbthomason/packer.nvim/issues/643#issuecomment-939296777

Thanks, that fixes my problem with local plugins. The documentation of the option "lock" and what is documented about it still are not consistent, though.