SourcePost event not triggered with :packadd

[ymic9963]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.test

Question

I've installed mini.test on its own, and due to the plugin not having a plugin/mini.test/test.lua (or similar) directory, it does not trigger a SourcePost event. Any idea how I would fix this?

[wmorin]

That's expected, and there's nothing to fix in mini.test. SourcePost fires once per file that gets sourced, and :packadd only sources the plugin's plugin/ and ftdetect/ scripts. The standalone mini.test repo only has lua/ and doc/, so :packadd mini.test adds it to runtimepath and sources nothing, hence no event. You'd see the same with any Lua-only plugin.

Quick check with a Lua-only plugin next to one that has a plugin/ file (Nvim 0.12):

after packadd mini.test: SourcePost hits={} rtp_has=true require_ok=true
after packadd withplugin: SourcePost hits={ "withplugin.lua" }

:packadd is synchronous though, so you don't need an event. Whatever you were hooking on SourcePost can just go right after it:

vim.cmd.packadd("mini.test")
require("mini.test").setup()

If you install it with vim.pack.add(), its load option can take a function that gets the plugin data, and then you're in charge of loading:

vim.pack.add({ "https://github.com/nvim-mini/mini.test" }, {
  load = function(p)
    vim.cmd.packadd(p.spec.name)
    require("mini.test").setup()
  end,
})

See :h :packadd and :h vim.pack.add().

[ymic9963]

I'm not sure if the second part of your reply is useful for my problem, but I'll elaborate on what I mean and why I need it. Apologies if I misunderstood.

An example of what I'm talking about is executing a setup on :packadd which I've pasted below for plugin foo. I don't need mini.test to be loaded every time I open Neovim. I understand the argument of "it doesn't have that much overhead", but it's not my point here since I want to have control what gets loaded and when.

-- Plugin foo is 'on-demand' and won't be loaded until :packadd
vim.pack.add({"repo/for/foo.nvim"}, {
    load = function() end
})

-- Load setups on :packadd
vim.api.nvim_create_autocmd("SourcePost", {
    group = config_augroup,
    callback = function(ev)
        local pluginname = vim.fs.basename(ev.file)

        if pluginname == 'foo.lua' and not package.loaded['foo'] then
            require("foo").setup()
        end
    end
})

Is my above example similar to what you were referring to? I hope I explained it well enough. This method works for plugins who have plugin/foo/foo.lua, as you've also mentioned.

[wmorin]

Got it, you want it on demand, not loaded at startup. Then there's no event to hook, unfortunately. :packadd mini.test only adds the directory to runtimepath, and since the plugin has no plugin/ file nothing is sourced, so SourcePost never fires for it. I also checked SourcePre and OptionSet on runtimepath: neither fires on :packadd either.

What works is doing the :packadd yourself through a small command, so you still decide when it loads and the setup runs right after:

local setups = {
  ["mini.test"] = function() require("mini.test").setup() end,
}

vim.api.nvim_create_user_command("Packadd", function(opts)
  vim.cmd.packadd(opts.args)
  local setup = setups[opts.args]
  if setup then setup() end
end, { nargs = 1, complete = "packadd" })

Then :Packadd mini.test loads it and runs its setup (with the real mini.test, MiniTest exists right after), and tab completion still lists your opt packages. Plugins that aren't in the table just get a plain :packadd, so you can use it for everything and keep your SourcePost approach for the ones that have a plugin/ file.

[ymic9963]

Ah I see. Thank you for the snippet. Unfortunate that there isn't a way of doing it using :packadd specifically. Is there a benefit to not having the plugin/ directory for mini.test? Even an empty plugin/mini.test/test.lua would be enough to trigger the event.

[echasnovski]

Is there a benefit to not having the plugin/ directory for mini.test? Even an empty plugin/mini.test/test.lua would be enough to trigger the event.

Yes, there is a benefit in that it is not needed for a properly working standalone plugin.

[ymic9963]

I understand that it is not needed but what is the benefit? The benefit is that you don't include a plugin/foo/foo.lua directories and file?

[echasnovski]

I understand that it is not needed but what is the benefit? The benefit is that you don't include a plugin/foo/foo.lua directories and file?

The benefit is not included empty file that serves no (widely useful) purpose. The idea that including an empty file can be beneficial makes (to me) the whole approach behind it questionable.

[echasnovski]

I've installed mini.test on its own, and due to the plugin not having a plugin/mini.test/test.lua (or similar) directory, it does not trigger a SourcePost event. Any idea how I would fix this?

The answer to this particular question is "The fix depends on what you try to achieve. This behavior is expected, precisely because of what you described". There is no need in 'plugin/mini-test.lua' in standalone repo, since they are all designed to be merely a copy of 'mini.nvim' parts with all their suggested workflows.

An example of what I'm talking about is executing a setup on :packadd which I've pasted below for plugin foo. I don't need mini.test to be loaded every time I open Neovim. I understand the argument of "it doesn't have that much overhead", but it's not my point here since I want to have control what gets loaded and when.

Depends on what you mean by "to be loaded". Usually the problem here is wanting to delay sourcing plugin/* files since this introduces side effects (mappings, user commands, autocommands, highlight groups). If not doing that is enough to qualify as "to not be loaded", then executing :packadd during startup is fine (since there are plugin/*).

My personal preference and recommendation is to not do SourcePost approach, since it is not quite reliable (as this question reveals). The "two stage" loading "now and later" type is usually good enough for most configs. Like it is done in MiniMax, for example.

If you want to completely avoid increasing 'runtimepath' completely, then doing two steps (:packadd + :lua require('mini.test').setup()) manually or via some helper command is the way to go.

Finally, the solution for 'mini.test' specific case:

• It doesn't really need the require('mini.test').setup() for the correct operation. Skipping it will not create default highlight groups and global _G.MiniTest, which might be fine.
• Use 'mini.nvim' directly. If you use at least one other module, then it would add less 'runtimepath' overhead.

Hope this helps.

[ymic9963]

Depends on what you mean by "to be loaded". Usually the problem here is wanting to delay sourcing plugin/* files since this introduces side effects (mappings, user commands, autocommands, highlight groups). If not doing that is enough to qualify as "to not be loaded", then executing :packadd during startup is fine (since there are plugin/*).

I'm confused about what you said here. In mini.test's case there isn't a plugin/ directory, therefore it can't be loaded using a :packadd with the method I described in my reply. So what you're suggesting here can't be done with mini.test.

My personal preference and recommendation is to not do SourcePost approach, since it is not quite reliable (as this question reveals)

Are there issues with the method itself or is it because plugin authors don't always inlcude the plugin/ directory?

Use 'mini.nvim' directly. If you use at least one other module, then it would add less 'runtimepath' overhead.

I only use mini.test, but there still isn't a plugin/ directory in mini.nvim so what I'd like to do here won't work.

Also, just to ask the same question to yourself as well: Is there a benefit to not having the plugin/ directory for mini.test? Even an empty plugin/mini.test/test.lua would be enough to trigger the event.

[echasnovski]

Depends on what you mean by "to be loaded". Usually the problem here is wanting to delay sourcing plugin/* files since this introduces side effects (mappings, user commands, autocommands, highlight groups). If not doing that is enough to qualify as "to not be loaded", then executing :packadd during startup is fine (since there are plugin/*).

I'm confused about what you said here. In mini.test's case there isn't a plugin/ directory, therefore it can't be loaded using a :packadd with the method I described in my reply. So what you're suggesting here can't be done with mini.test.

Again, it depends on what you mean by "to be loaded". Doing :packadd is essentially two things: 1) add plugin path to 'runtimepath'; 2) execute plugin scripts immediately. Since standalone 'mini.test' doesn't have plugin scripts, doing :packadd mini.test will only modify 'runtimepath'. If this is not the problem for you, then using plain vim.pack.add during startup (without load = function() end) should be fine.

To perform side effects later, execute :lua require('mini.test').setup(). Although they are not a hard requirement for 'mini.test'.

My personal preference and recommendation is to not do SourcePost approach, since it is not quite reliable (as this question reveals)

Are there issues with the method itself or is it because plugin authors don't always inlcude the plugin/ directory?

Because both not all plugin authors provide setup() to initialize plugin and not all plugin authors include plugin script. This prompts this SourcePost autocommand to manually track "plugin script name" -> "Lua module" relation. As this is needed, there are less magical ways of doing things: implement a custom user command :packadd alternative, use "two stage" loading, etc.

Use 'mini.nvim' directly. If you use at least one other module, then it would add less 'runtimepath' overhead.

I only use mini.test, but there still isn't a plugin/ directory in mini.nvim so what I'd like to do here won't work.

Also, just to ask the same question to yourself as well: Is there a benefit to not having the plugin/ directory for mini.test? Even an empty plugin/mini.test/test.lua would be enough to trigger the event.

See this response.

[ymic9963]

Again, it depends on what you mean by "to be loaded"

For me loaded in this case would be to be able to use the plugin from Neovim itself. Therefore, for mini.test it would be the ability to access the global object with :lua MiniTest.X().

Thank you for your replies! I really appreciate it. I'll figure out another way of doing what I want to do.

[echasnovski]

Therefore, for mini.test it would be the ability to access the global object with :lua MiniTest.X().

For 'mini.test', it can also be :lua require('mini.test').X(), which works without calling require('mini.test').setup().