Packer.nvim: Conditional activation and local plugins

[akinsho]

I've recently switched over to packer (and it's really great 🙌🏿 ) and recently hit #118. I'm raising this issue/question separately though as more generally I'm trying to figure out the best way to handle conditional activation similar to how it can be handled in vim-plug

For example I work on a few personal plugins and contribute to a few others so whilst using vim-plug I had a work flow that resembled the block below in vimscript i.e. using an env variable to decide whether to load the local plugins or not.

     if vim.env.DEVELOPING then
       local_use "contributing/local-version.lua"
     else
       use "upstream/version.lua"
     end

I've tried something similar in packer and hit #118, although once that is resolved it seems I'd still hit a similar issue to vim plug without a similar work around which is that packer clean would try re-install the local or upstream plugin every time I switched over. Whereas ideally what I'd want is the plugin to be installed and remain installed but not be loaded till a condition is met.

I've tried using the cond key for example with

    use {
      "christoomey/vim-tmux-navigator",
      opt = true,
      cond = function()
        return vim.env.TMUX ~= nil
      end
    }

but this doesn't seem to prevent the plugin from being loaded as when I run this outside tmux the plugin still appears in my runtimepath echo globpath(&rtp, 'pack/packer/*/vim-tmux-navigator')

This could be a misunderstanding on my part, so happy to add any clarification to the docs?

also as a side note I've guessed that checking &rtp is the best way to find out if a plugin is actually loaded or not (I'm not sure if this is correct tbh) since there isn't a Plug{Packer}Status command

[Iron-E]

Does :scriptnames say that vim-tmux-navigator has been run? Something can be in your &rtp but also not be interacted with.

[akinsho]

@Iron-E, thanks for the heads up you're right it doesn't seem to be in the list of scripts, so condition is working correctly 👍🏿 .

I guess in this case I can use conditionals with both if to prevent it being installed at all and cond = <thing> to allow the thing to be installed but deactivated. One lingering question that I think then is probably more related to #137 is how to have both at the same time.

In my case say the condition was an env var I'm flipping is there a way to ensure that both things are kept installed. That's the main value of the Cond function that vim plug wiki shows (link in the issue description). The way that works means that PlugClean doesn't try and remove the plugin, so the local and upstream ones co-exist, which is more valuable in packer's case the local plugin I believe is a symlink.

e.g.

-- both are installed but only one is ever active at a time
use {"~/my-local-plugin", cond = function() return var ~= nil end }
use {"my-remote-plugin", cond = function() return var == nil end }

I'll move the question over there and close this out since it was primarily about how conditional activation was working.

🤔 as an aside scriptnames is kind of a cumbersome way of knowing (programmatically) if something was loaded any ideas if there is a tidier way?. The help docs include a way of putting that into a map but just hoping to avoid that bit of vimscript.

[akinsho]

Actually scriptnames doesn't show lua plugins, so essentially it's very hard to know if a plugin was actually loaded or not 😅 , won't derail the conversation here but it means adding guards to your config based on if a plugin was loaded or not is quite tough

[Iron-E]

Actually scriptnames doesn't show lua plugins

Whoops, you're right. Those can be found in the package.loaded lua module.

print(vim.inspect(package.loaded))

Anything which has been required will be there.

how to have both at the same time.

Since packer.nvim uses the plugin name to track plugins, my guess is that your local and remote plugins appear equivalent (though I'm not certain). If you want to find out for sure, you can use the as key to alias the local plugin name to something different.

That should allow both to be installed and maintained, with only cond separating the load condition

In the provided example (my-local vs my-remote) I believe it should see both without needing to alias.

[akinsho]

Good call re. package.loaded 👍🏿 definitely issue creep but it'd be nice if you could introspect the plugins packer loaded more easily, for example for programmatic access vim-plug has g:plugs although you have to cross reference this with the rtp.

Re. the local and remote plugin being detected the same, I'm guessing that's the cause of #118. Not sure how or why but aliasing using as doesn't work. I tried this out locally and what I see is the plugins get saved under the alias in my case I added a local-<plug-name> prefix so this should allow them to co-exist with the upstream variant but with either side installed the other isn't picked up. Whatever the mechanic from #118 it seems to happen regardless of an alias 🤷🏿‍♂️ . I'll close this here and comment on what I found in that issue since it all relates to that bug really and how it is resolved

[Iron-E]

As an aside I think cond might need another looking at. I just tried to convert my bootleg-manual-packadd approach into using conds for each plugin which specify a requirement of nvim-0.5, and I got a bunch of errors regarding loadstring()s and I wasn't able to get it to work at all.

Gave up and went back to the old approach which doesn't actually have packer handle anything, it just sets things to opt and then creates another file for conditional loading.

One or two conditions usually works, but having every single plugin specified to various different conditions tends to make it act out.

[akinsho]

@Iron-E I found that as reported in a few other issues you must not use any local variables in your condition function or packer errors obscurely. I tend to alias things like vim.fn.x to x and that won't do in a condition. Although you might already have known this and were referring to something else. Tbh I only have the one atm and it works.

[Iron-E]

you must not use any local variables in your condition function or packer errors obscurely.

Oh, that would be it. I was trying to abstract my config into a more general wrapper so i could pass true/false values and it would create a new function for me special for each plugin, but I can see now that the approach I was taking won't work.

Thanks for the heads up!

[wbthomason]

Yes, sorry, this is a common stumbling block - because Lua's string.dump cannot tolerate closures, you cannot use them (i.e. have functions which close over local variables) in config, setup, or cond keys. Sorry about that!