Repository navigation
Unable to run denops with deno in a container #467
Description
Describe the bug
Provide a minimal vimrc with less than 50 lines to reproduce
For neovim (haven't tried it in vim):
vim.pack.add({
"https://github.com/vim-denops/denops.vim",
"https://github.com/vim-denops/denops-helloworld.vim"
})
vim.g["denops#debug"] = 1
vim.g["denops#server#deno"] = "podman"
vim.g["denops#server#deno_args"] = {
"-v", vim.env.HOME .. ":" .. vim.env.HOME,
"--network=host",
"ghcr.io/denoland/deno",
"deno",
"run",
unpack(vim.g["denops#server#deno_args"])
}This is an ugly hack that only works because deno run and podman run share the same subcommand, normally I am using a shell script with podman args, this is just for ease of testing.
How to reproduce the problem from Vim startup
podman pull ghcr.io/denoland/deno
nvim -u init.lua
[denops] Spawn server [0/3]
[denops] Server started: ['podman', 'run', '-v', '/home/szymon:/home/szymon', '--network=host', 'ghcr.io/denoland/deno', 'deno', 'run', '-q', '--no-lock', '-A', '--config', '/home/szymon/.lo
cal/share/nvim/site/pack/core/opt/denops.vim/denops/@denops-private/deno.jsonc', '/home/szymon/.local/share/nvim/site/pack/core/opt/denops.vim/denops/@denops-private/cli.ts', '--quiet', '--i
dentity', '--port', '0']
[denops] Server listen: 127.0.0.1:36799
[denops] Channel connected (127.0.0.1:36799)
[denops] Channel closed (127.0.0.1:36799)
[denops] DenopsClosed
Expected behavior
DenoHello available and works.
Actual behavior
It seems that denops doesn't fully start, no commands are available, DenoHello is not either. All of it does work if I run deno outside of a container.
Screenshots (if need)
Your environment
- OS:
Linux 6.17.0-23-generic #23~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 14 16:11:48 UTC 2 x86_64 x86_64 x86_64 GNU/Linuxtried it also on different computers - Deno version:
deno 2.7.14 - Neovim version:
v0.12.3-dev-78+g25b522a75dtried it also on stable - Denops version:
commit 1df7a022d6e9cb3f6a3db43235e0f174ccd79e03 (HEAD, tag: v8.0.2)
Activity
Shougo commentedon May 13, 2026
Thanks for the detailed report and reproduction steps.
From the debug log, it looks like the local denops server process is actually starting and listening successfully:
Server started: ...Server listen: 127.0.0.1:36799Channel connected (127.0.0.1:36799)So this does not look like a simple failure to spawn
denoinside the container, nor a basic networking issue.The part that looks suspicious is that the channel closes immediately after connect, before denops becomes ready:
Channel connected (...)Channel closed (...)DenopsClosedLooking at the startup flow,
DenopsReadyis only emitted after the workerfinishes its initialization. In other words, the failure seems to happen after
the socket connection is established, but before the worker reaches the
DenopsSystemReadystage.That suggests one of these is happening inside the containerized
deno run ... cli.ts ...process:Could you try collecting the stderr output from the containerized process more
explicitly? The most useful next step would be to capture any error printed by
the worker itself.
It would also help to try the same setup with slightly different
podman runflags, for example:-i--rm-e HOME=$HOMEand-w $HOMEAt this point, my impression is:
So the issue is likely in the worker/runtime environment inside the container rather than in the initial spawn step itself.
If you can provide the full stderr from the container side, that should make it much easier to identify the exact failure point.
Ashymad commentedon May 13, 2026
So I run denops separately to capture the stderr and found the issue. Denops need
gitcommand to be availabledenops.vim/denops/@denops-private/version.ts
Lines 10 to 16 in 1df7a02
If it's not there then it stops denops from working, but doesn't crash deno, which leads to this issue.
For my purpose I just created a small Containerfile and with that it works.
I think to avoid this in the future either a clear message should be displayed if git is not found, or some other way of getting the version could be figured out, the
gitcall seems fragile at best.Shougo commentedon May 14, 2026
@Ashymad Please test #468.
Ashymad commentedon May 14, 2026
@Shougo thank you very much for fixing this. Now it works without having to add git to the image.