Unable to run denops with deno in a container

[Ashymad]

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/Linux tried it also on different computers
• Deno version: deno 2.7.14
• Neovim version: v0.12.3-dev-78+g25b522a75d tried it also on stable
• Denops version: commit 1df7a022d6e9cb3f6a3db43235e0f174ccd79e03 (HEAD, tag: v8.0.2)

Additional context

[Shougo]

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:36799
• Channel connected (127.0.0.1:36799)

So this does not look like a simple failure to spawn deno inside 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 (...)
• DenopsClosed

Looking at the startup flow, DenopsReady is only emitted after the worker
finishes its initialization. In other words, the failure seems to happen after
the socket connection is established, but before the worker reaches the
DenopsSystemReady stage.

That suggests one of these is happening inside the containerized deno run ... cli.ts ... process:

• worker initialization fails with an exception
• host/service initialization fails
• the worker exits immediately, which causes the channel to close from the Vim/Neovim side

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 run flags, for example:

• -i
• --rm
• possibly explicit env/workdir settings such as -e HOME=$HOME and -w $HOME

At this point, my impression is:

• process spawn: OK
• TCP connect back to host: OK
• denops worker becomes ready: NG

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]

So I run denops separately to capture the stderr and found the issue. Denops need git command to be available

denops.vim/denops/@denops-private/version.ts

Lines 10 to 16 in 1df7a02

	const command = new Deno.Command("git", {
	args: ["describe", "--tags", "--always"],
	cwd,
	stdin: "null",
	stdout: "piped",
	stderr: "null",
	});

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.

FROM ghcr.io/denoland/deno:alpine
RUN apk add git

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 git call seems fragile at best.

[Shougo]

@Ashymad Please test #468.

[Ashymad]

@Shougo thank you very much for fixing this. Now it works without having to add git to the image.