Repository navigation
[Issue] Conditions not always respected #7
Description
When I copy my configs in a new machine i.e. building it from scratch, at the very beginning, I get prompted to install all plugins, regardless of their enabled status. If I press N, then I get asked to install zpack. I press Y, Then it correctly detects the enabled plugins, and only asks to install those.
It's probably a bug in the loading order for plugins.
Also, I get asked to install all (not ALL, the enabled ones) plugins whenever I push a lockfile to a new machine. Can the behavior be changed to what Lazy does i.e. only ask for the new ones?
Also, just a silent bug, if I have a plugin spec that combines simple and complex plugins like
return {
"repo1/plugin1",
{
"repo2/plugin2",
opts = { ... },
},
}the whole file is ignored. If I wrap all in {} it works. I'm fine by that since it sort of normalizes configs, but ignoring silently is not nice.
Sorry for all these issues, I just migrated to zpack from lazy.nvim, and wanted to make it easier for future migrators. My migrated config can be found at https://github.com/SinTan1729/my-nvim-config in case it makes it easier for you to test. Look at the migration branch.
Activity
SinTan1729 commentedon Apr 8, 2026
Also, it seems that lazy loading logic is a bit different here compared to
lazy.nvim, since the number of loaded plugins seems to differ. Not a big deal though. I'm seeing comparable startup times (~150ms with the full config, ~100ms with just the core) after migration.zuqini commentedon Apr 8, 2026
No worries at all! I really appreciate the feedback. It helps make zpack better for everyone.
This is likely caused by a stale lockfile. Your lockfile contains entries for all plugins (including ones behind
enabled = false), and on a fresh machine, the nativevim.packreads the lockfile and prompts for everything before zpack is even loaded, so zpack's enabled filtering never kicks in. Deleting the lockfile and running:ZUpdateto regenerate it based on the current specs should fix this going forward.:ZRestoredelegates tovim.pack.update(plugins, { target = 'lockfile' }), which restores all plugins to the lockfile state rather than computing a diff of what's missing. I need to think about whether this is something zpack should handle (computing the delta) or if it's better left tovim.packupstream. Will keep this in mind.This is a real bug — the spec detection heuristic can't distinguish between a single spec like
{ "user/repo", opts = {} }and a list where the first element is a bare string like{ "user/repo", { "user/repo2", ... } }. I'll work on a fix for this.Could you share how you're checking the loaded plugin count and which plugins are unexpectedly loaded in zpack? That would help me figure out whether it's a real discrepancy or just a difference in how loaded plugins are reported.
SinTan1729 commentedon Apr 8, 2026
Thanks for the response. I was using
:ZShow. It maybe a bug there as well.But I've found a real issue where the syntax and
cmparen't loaded.You can see above that the syntax isn't working properly e.g. the comments aren't grey as they should be. Also,
cmpdoesn't work with the LSP. I simply get no auto-completion.The behavior isn't fixed even if I forcefully load
nvim-cmpusingZLoad.It seems to me like some of the opts/config entries are being silently ignored as well.
zuqini commentedon Apr 8, 2026
I merged a fix that should address most, if not all, of the issues you're seeing here.
Do you mind verifying on your side if there's anything not covered by #8?
SinTan1729 commentedon Apr 8, 2026
Thanks for the quick fix. LGTM. I'll keep testing on my end, and maybe bother you further if issues arise.
zuqini commentedon Apr 8, 2026
@SinTan1729 Thank you for the awesome feedback btw! These are issues that I would likely have never encountered myself, so thank you for your patience while we iron out the kinks.
zuqini commentedon Apr 8, 2026
re: differing lazy loading behavior vs. lazy.nvim
I tested your plugins with lazy.nvim, and the only difference I found is plenary.nvim being silently forced to lazy by lazy.nvim's community specs, despite your config never setting it.
After digging into lazy.nvim's internals, here's the chain:
1. lazy.nvim's pkg system scans installed plugins
2. For plenary, rockspec.get() is called
3. It checks Community.get_spec("plenary.nvim") which returns { "nvim-lua/plenary.nvim", lazy = true }
4. This gets cached and added as a fragment
Since your spec
{ "nvim-lua/plenary.nvim" }never sets lazy, lazy.nvim's fragment metatable chain falls through to the community spec'slazy = true. If you explicitly setlazy = false, your config would take precedence.Reference: https://github.com/folke/lazy.nvim/blob/306a05526ada86a7b30af95c5cc81ffba93fef97/lua/lazy/community/specs.lua#L5
For this particular difference, I don't think it's in-scope for zpack. Let me know if you find other differences.
Looks like all of the issues here should be resolved. I'll close the issue, but feel free to open new ones if you find any other issues.
SinTan1729 commentedon Apr 8, 2026
Thanks again for the quick fixes. Regarding the behavior of
plenary, I decided to force it to be lazy since plenary is a passive plugin. Maybe you can consider adding it to the the migration tips.docs: add migration notes for install feedback and passive libraries
docs: add migration notes for install feedback and passive libraries