Headless updates with mini.deps

[KimNorgaard]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.deps

Question

I have an update script that updates various packages, etc. on MacOS. I would like to also update Neovim plugins.

To do this I currently run:

nvim --headless -c +'lua MiniDeps.update(nil, { force = true })' +TSUpdateSync +qa

However this doesn't seem to do the trick. It downloads the updates but doesn't seem to install them. When I run this and run :DepsUpdate from Neovim afterwards I get the usual buffer where I need to :w to install the updates.

Is it possible doing headless updates?

[echasnovski]

I am not sure if this is easily possible. The overall update process was designed to be non-blocking, so maybe this is a major road block here. I'll have to take a closer look.

[echasnovski]

Running this exact command seems to have worked for me:

nvim --headless -c +'lua MiniDeps.update(nil, { force = true })' +TSUpdateSync +qa

The trick here is that it only updates plugins which are currently added to the session (with default nil). I.e. the ones which you add with now. The ones added with later are not yet in session during this way of MiniDeps.update() execution.

Running that command did take some time (as usual as with interactive "in-session" update) and indeed updated plugins that were loaded with now().

However this doesn't seem to do the trick. It downloads the updates but doesn't seem to install them.

Let's check this more thoroughly:

• What does :DepsShowLog show after executing the CLI command with update? It should contain an entry like ========== Update 2025-03-13 20:12:13 ========== with plugins that are added with now (even if they didn't have any updates).
• What is the state (Git commit) of actually updated plugins? For example, I had an log entry that showed updates to nvim-treesitter. I navigated to '~/.local/share/nvim/site/pack/deps/opt/nvim-treesitter' and it indeed showed that its on the latest commit from the update (i.e. updates did apply as expected).

[KimNorgaard]

Thank for you looking into this. It seems you are right. From looking at my logs and git status it does update the now() plugins but not the later() plugins.

So the question is if there is a way forward/around here or if it's by design/too much work? It's probably not the most wide spread use case :)

[KimNorgaard]

I wonder if wrapping MiniDeps.update() in vim.schedule would force it to run later?

[echasnovski]

I wonder if wrapping MiniDeps.update() in vim.schedule would force it to run later?

If anything, it should be MiniDeps.later() instead of vim.schedule().

So the question is if there is a way forward/around here or if it's by design/too much work? It's probably not the most wide spread use case :)

Only hacky workaround, I am afraid. After trial and error, something like this should work:

nvim --headless -c +"lua MiniDeps.later(function() MiniDeps.update(nil, { force = true }); vim.cmd('TSUpdateSync'); vim.cmd('qa') end); vim.wait(30000)"

What it does:

• Registers a later() callback (which should be executed after all later() callbacks from the 'init.lua') and asks Neovim to wait for 30 seconds until proceeding.
• The later() callback does force update which is done non-blocking but synchronously (i.e. it is not going to the next line/command until this one is finished; I now vaguely remember that this particular headless case was the motivation behind this design). Only after that :TSUpdateSync is run followed by qa!.

---

Note for clarity and possibly future self. Using "all plugins in session" as default for MiniDeps.update() is mostly motivated by the fact that using "all plugins in '~/.local/share/nvim/site/pack/deps/'" has the following caveats:

• A use case of "I want to have many plugins available but load only handful" seems like a valid one. So if the user previously run :DepsAdd author/plugin for a quick look at a plugin, it would still be updated during update() even if not currently loaded.
• Plugins not in session do not define checkout target. It is possible to use default target for them (i.e. usually master or main), but it might conflict with previous uses of the plugin.

An opposite problem here with using "all plugins in session" is this question: if plugin is added with later(), it can not be easily updated with "headless approach". But as there is a workaround, it might be not that bad. I can not think of other downsides of this approach.

None of these points are huge problems, but mostly contribute to a design decision.

[KimNorgaard]

Thank you. The workaround is fine for my use case and seeing that I choose mini.deps exactly because it has a small footprint I am perfectly happy that you don't have to add code to fix my problem :)