5
30
Fork
You've already forked nvim-dev-container
3

Question: How to setup the extension? #149

Open
opened 2026年03月13日 17:34:19 +01:00 by mmartinortiz · 9 comments

Hi,

After setting up the extension I always get the same error, no matter what Devcontainer command I use:

Error executing Lua callback: ...vim-dev-container/lua/devcontainer/config_file/parse.lua:127: bad argument #1 to 'fs_stat' (string expected, got nil)
stack traceback:
	[C]: in function 'fs_stat'
	...vim-dev-container/lua/devcontainer/config_file/parse.lua:127: in function 'parse_nearest_devcontainer_config'
	...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:22: in function 'get_nearest_devcontainer_config'
	...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:848: in function 'attach_auto'
	...e/nvim/lazy/nvim-dev-container/lua/devcontainer/init.lua:208: in function <...e/nvim/lazy/nvim-dev-container/lua/devcontainer/init.lua:198>

If I understand the log correctly, the extension is not able to find the devcontainer.json file. Because I do not thing it is a bug, but a problem between the screen and the chair, let me explain my setup to understand if I made it correctly:

  • nvim v0.11.6 installed with brew
  • Using lazyvim
  • Edit ~/.config/nvim/lua/plugins/devcontainer.lua
  • Create the config. See [1]
  • Go to a folder with a project that uses devcontainer.json
  • Open nvim, open the lazy menu, make sure everything is up to date
  • Use the command DevcontainerAttach (container already built using the devcontainer cli

[1] This is my config:

return {
 "https://codeberg.org/esensar/nvim-dev-container",
 config = function()
 require("devcontainer").setup({
 config_search_start = function()
 -- By default this function uses vim.loop.cwd()
 -- This is used to find a starting point for .devcontainer.json file search
 -- Since by default, it is searched for recursively
 -- That behavior can also be disabled
 end,
 workspace_folder_provider = function()
 -- By default this function uses first workspace folder for integrated lsp if available and vim.loop.cwd() as a fallback
 -- This is used to replace `${localWorkspaceFolder}` in devcontainer.json
 -- Also used for creating default .devcontainer.json file
 end,
 terminal_handler = function(command)
 -- By default this function creates a terminal in a new tab using :terminal command
 -- It also removes statusline when that tab is active, to prevent double statusline
 -- It can be overridden to provide custom terminal handling
 end,
 nvim_installation_commands_provider = function(path_binaries, version_string)
 -- Returns table - list of commands to run when adding neovim to container
 -- Each command can either be a string or a table (list of command parts)
 -- Takes binaries available in path on current container and version_string passed to the command or current version of neovim
 end,
 -- Can be set to true to install neovim as root in container
 -- Usually not required, but could help if permission errors occur during install
 nvim_install_as_root = false,
 devcontainer_json_template = function()
 -- Returns table - list of lines to set when creating new devcontainer.json files
 -- As a template
 -- Used only when using functions from commands module or created commands
 end,
 -- Can be set to false to prevent generating default commands
 -- Default commands are listed below
 generate_commands = true,
 -- By default no autocommands are generated
 -- This option can be used to configure automatic starting and cleaning of containers
 autocommands = {
 -- can be set to true to automatically start containers when devcontainer.json is available
 init = false,
 -- can be set to true to automatically remove any started containers and any built images when exiting vim
 clean = false,
 -- can be set to true to automatically restart containers when devcontainer.json file is updated
 update = false,
 },
 -- can be changed to increase or decrease logging from library
 log_level = "info",
 -- can be set to true to disable recursive search
 -- in that case only .devcontainer.json and .devcontainer/devcontainer.json files will be checked relative
 -- to the directory provided by config_search_start
 disable_recursive_config_search = false,
 -- can be set to false to disable image caching when adding neovim
 -- by default it is set to true to make attaching to containers faster after first time
 cache_images = true,
 -- By default all mounts are added (config, data and state)
 -- This can be changed to disable mounts or change their options
 -- This can be useful to mount local configuration
 -- And any other mounts when attaching to containers with this plugin
 attach_mounts = {
 neovim_config = {
 -- enables mounting local config to /root/.config/nvim in container
 enabled = true,
 -- makes mount readonly in container
 options = { "readonly" },
 },
 neovim_data = {
 -- enables mounting local data to /root/.local/share/nvim in container
 enabled = false,
 -- no options by default
 options = {},
 },
 -- Only useful if using neovim 0.8.0+
 neovim_state = {
 -- enables mounting local state to /root/.local/state/nvim in container
 enabled = false,
 -- no options by default
 options = {},
 },
 },
 -- This takes a list of mounts (strings) that should always be added to every run container
 -- This is passed directly as --mount option to docker command
 -- Or multiple --mount options if there are multiple values
 always_mount = {},
 -- This takes a string (usually either "podman" or "docker") representing container runtime - "devcontainer-cli" is also partially supported
 -- That is the command that will be invoked for container operations
 -- If it is nil, plugin will use whatever is available (trying "podman" first)
 container_runtime = "docker",
 -- Similar to container runtime, but will be used if main runtime does not support an action - useful for "devcontainer-cli"
 backup_runtime = nil,
 -- This takes a string (usually either "podman-compose" or "docker-compose") representing compose command - "devcontainer-cli" is also partially supported
 -- That is the command that will be invoked for compose operations
 -- If it is nil, plugin will use whatever is available (trying "podman-compose" first)
 compose_command = nil,
 -- Similar to compose command, but will be used if main command does not support an action - useful for "devcontainer-cli"
 backup_compose_command = nil,
 })
 end,
}
Hi, After setting up the extension I always get the same error, no matter what `Devcontainer` command I use: ```bash Error executing Lua callback: ...vim-dev-container/lua/devcontainer/config_file/parse.lua:127: bad argument #1 to 'fs_stat' (string expected, got nil) stack traceback: [C]: in function 'fs_stat' ...vim-dev-container/lua/devcontainer/config_file/parse.lua:127: in function 'parse_nearest_devcontainer_config' ...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:22: in function 'get_nearest_devcontainer_config' ...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:848: in function 'attach_auto' ...e/nvim/lazy/nvim-dev-container/lua/devcontainer/init.lua:208: in function <...e/nvim/lazy/nvim-dev-container/lua/devcontainer/init.lua:198> ``` If I understand the log correctly, the extension is not able to find the `devcontainer.json` file. Because I do not thing it is a bug, but a problem between the screen and the chair, let me explain my setup to understand if I made it correctly: - `nvim` `v0.11.6` installed with `brew` - Using `lazyvim` - Edit `~/.config/nvim/lua/plugins/devcontainer.lua` - Create the config. See [1] - Go to a folder with a project that uses `devcontainer.json` - Open `nvim`, open the `lazy` menu, make sure everything is up to date - Use the command `DevcontainerAttach` (container already built using the `devcontainer cli` [1] This is my config: ```lua return { "https://codeberg.org/esensar/nvim-dev-container", config = function() require("devcontainer").setup({ config_search_start = function() -- By default this function uses vim.loop.cwd() -- This is used to find a starting point for .devcontainer.json file search -- Since by default, it is searched for recursively -- That behavior can also be disabled end, workspace_folder_provider = function() -- By default this function uses first workspace folder for integrated lsp if available and vim.loop.cwd() as a fallback -- This is used to replace `${localWorkspaceFolder}` in devcontainer.json -- Also used for creating default .devcontainer.json file end, terminal_handler = function(command) -- By default this function creates a terminal in a new tab using :terminal command -- It also removes statusline when that tab is active, to prevent double statusline -- It can be overridden to provide custom terminal handling end, nvim_installation_commands_provider = function(path_binaries, version_string) -- Returns table - list of commands to run when adding neovim to container -- Each command can either be a string or a table (list of command parts) -- Takes binaries available in path on current container and version_string passed to the command or current version of neovim end, -- Can be set to true to install neovim as root in container -- Usually not required, but could help if permission errors occur during install nvim_install_as_root = false, devcontainer_json_template = function() -- Returns table - list of lines to set when creating new devcontainer.json files -- As a template -- Used only when using functions from commands module or created commands end, -- Can be set to false to prevent generating default commands -- Default commands are listed below generate_commands = true, -- By default no autocommands are generated -- This option can be used to configure automatic starting and cleaning of containers autocommands = { -- can be set to true to automatically start containers when devcontainer.json is available init = false, -- can be set to true to automatically remove any started containers and any built images when exiting vim clean = false, -- can be set to true to automatically restart containers when devcontainer.json file is updated update = false, }, -- can be changed to increase or decrease logging from library log_level = "info", -- can be set to true to disable recursive search -- in that case only .devcontainer.json and .devcontainer/devcontainer.json files will be checked relative -- to the directory provided by config_search_start disable_recursive_config_search = false, -- can be set to false to disable image caching when adding neovim -- by default it is set to true to make attaching to containers faster after first time cache_images = true, -- By default all mounts are added (config, data and state) -- This can be changed to disable mounts or change their options -- This can be useful to mount local configuration -- And any other mounts when attaching to containers with this plugin attach_mounts = { neovim_config = { -- enables mounting local config to /root/.config/nvim in container enabled = true, -- makes mount readonly in container options = { "readonly" }, }, neovim_data = { -- enables mounting local data to /root/.local/share/nvim in container enabled = false, -- no options by default options = {}, }, -- Only useful if using neovim 0.8.0+ neovim_state = { -- enables mounting local state to /root/.local/state/nvim in container enabled = false, -- no options by default options = {}, }, }, -- This takes a list of mounts (strings) that should always be added to every run container -- This is passed directly as --mount option to docker command -- Or multiple --mount options if there are multiple values always_mount = {}, -- This takes a string (usually either "podman" or "docker") representing container runtime - "devcontainer-cli" is also partially supported -- That is the command that will be invoked for container operations -- If it is nil, plugin will use whatever is available (trying "podman" first) container_runtime = "docker", -- Similar to container runtime, but will be used if main runtime does not support an action - useful for "devcontainer-cli" backup_runtime = nil, -- This takes a string (usually either "podman-compose" or "docker-compose") representing compose command - "devcontainer-cli" is also partially supported -- That is the command that will be invoked for compose operations -- If it is nil, plugin will use whatever is available (trying "podman-compose" first) compose_command = nil, -- Similar to compose command, but will be used if main command does not support an action - useful for "devcontainer-cli" backup_compose_command = nil, }) end, } ```

Hi, thanks for reporting this. I think I need to updated that README. This configuration is not ready to be just copied over (especially with these first couple of functions - I think these are causing issues. Can you remove all of these empty functions from the configuration on top? Once they are not there, the defaults will be used. This way these empty functions are used instead of defaults, resulting in nil locations for devcontainer.json file.

Hi, thanks for reporting this. I think I need to updated that README. This configuration is not ready to be just copied over (especially with these first couple of functions - I think these are causing issues. Can you remove all of these empty functions from the configuration on top? Once they are not there, the defaults will be used. This way these empty functions are used instead of defaults, resulting in `nil` locations for devcontainer.json file.

Ok, I keep now a bare minimum config:

return {
 "https://codeberg.org/esensar/nvim-dev-container",
 config = function()
 require("devcontainer").setup({
 container_runtime = "docker",
 })
 end,
}

This is the error for DevcontainerAttach

Error executing vim.schedule lua callback: ...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:871: attempt to index local 'container' (a nil value)
stack traceback:
	...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:871: in function 'callback'
	...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:28: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

And for DevcontainerStart

Running built image (mcr.microsoft.com/devcontainers/base:ubuntu) failed!

Where could I find more details about this last error?

Those same errors are also risen if I use the devcontainer up ... before starting nvim.

Ok, I keep now a bare minimum config: ```lua return { "https://codeberg.org/esensar/nvim-dev-container", config = function() require("devcontainer").setup({ container_runtime = "docker", }) end, } ``` This is the error for `DevcontainerAttach` ``` Error executing vim.schedule lua callback: ...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:871: attempt to index local 'container' (a nil value) stack traceback: ...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:871: in function 'callback' ...im/lazy/nvim-dev-container/lua/devcontainer/commands.lua:28: in function '' vim/_editor.lua: in function <vim/_editor.lua:0> ``` And for `DevcontainerStart` ``` Running built image (mcr.microsoft.com/devcontainers/base:ubuntu) failed! ``` Where could I find more details about this last error? Those same errors are also risen if I use the `devcontainer up ...` before starting `nvim`.

Can you try running that image directly with docker? If you get the same issue with devcontainer up ..., then I doubt it is a plugin issue. Attach also fails because of the failed start (I just need to make clearer errors, and not just let the plugin fail 😄 )

Can you try running that image directly with `docker`? If you get the same issue with `devcontainer up ...`, then I doubt it is a plugin issue. Attach also fails because of the failed start (I just need to make clearer errors, and not just let the plugin fail 😄 )

Sure. First, I deleted all previous containers related to this devcontainer.

Then, I used devcontainer up... and run a docker exec -it ... /bin/bash. I could get into the container and see that things were OK (mounts, features, etc).

The same container can be used by vscode or zed.

Where can I find more logs about the error shown by the plugin? I'm still thinking that the issue is caused by something I'm not doing correctly :-)

Sure. First, I deleted all previous containers related to this devcontainer. Then, I used `devcontainer up...` and run a `docker exec -it ... /bin/bash`. I could get into the container and see that things were OK (mounts, features, etc). The same container can be used by `vscode` or `zed`. Where can I find more logs about the error shown by the plugin? I'm still thinking that the issue is caused by something I'm not doing correctly :-)

There is the DevcontainerLogs command. You can also check this to get more logs: https://codeberg.org/esensar/nvim-dev-container/src/branch/main/CONTRIBUTING.md#reporting-bugs

There is the `DevcontainerLogs` command. You can also check this to get more logs: https://codeberg.org/esensar/nvim-dev-container/src/branch/main/CONTRIBUTING.md#reporting-bugs

I found it!: a mount is reported as invalid

Fish shell is my preferred shell. All my containers have a mount for its individual fish history. This file is stored on the host in the path $HOME/.devcontainer/${devcontainerId}/fish_history and mounted in the container. The devcontainer.json has a init command to create the parent folders for the mount if they do not exist.

If I remove the mount, the command DevcontainerStart does not fail :-), DevcontainerAttach ask me to install nvim on the container and later to attach.

Is the devcontainerId variable supported by the plugin?

I found it!: a mount is reported as invalid Fish shell is my preferred shell. All my containers have a mount for its individual fish history. This file is stored on the host in the path `$HOME/.devcontainer/${devcontainerId}/fish_history` and mounted in the container. The `devcontainer.json` has a init command to create the parent folders for the mount if they do not exist. If I remove the mount, the command `DevcontainerStart` does not fail :-), `DevcontainerAttach` ask me to install `nvim` on the container and later to attach. Is the `devcontainerId` variable supported by the plugin?

Different question: After I attach to the nvim instance on the container, the Python interpreter used by nvim (according to healthcheck) is the one installed on the host. I find this strange, since the system path should not exist on the container. How can I confirm that my nvim instance is attached to the container?

Different question: After I attach to the `nvim` instance on the container, the Python interpreter used by `nvim` (according to `healthcheck`) is the one installed on the host. I find this strange, since the system path should not exist on the container. How can I confirm that my `nvim` instance is attached to the container?

Is the devcontainerId variable supported by the plugin?

No unfortunately, there is a limited number of vars supported (generally workspace folder related and env related vars). I can look into adding it.

> Is the `devcontainerId` variable supported by the plugin? No unfortunately, there is a limited number of vars supported (generally workspace folder related and env related vars). I can look into adding it.

@mmartinortiz wrote in #149 (comment):

Different question: After I attach to the nvim instance on the container, the Python interpreter used by nvim (according to healthcheck) is the one installed on the host. I find this strange, since the system path should not exist on the container. How can I confirm that my nvim instance is attached to the container?

Hmm yeah the experience with that is a bit bad. It is possible that nvim installation is just taking a while and you aren't yet attached. Generally, I guess it is easiest to try running some shell commands from nvim to confirm if you are in the container (e.g. :!hostname, or !ls /).

@mmartinortiz wrote in https://codeberg.org/esensar/nvim-dev-container/issues/149#issuecomment-11786676: > Different question: After I attach to the `nvim` instance on the container, the Python interpreter used by `nvim` (according to `healthcheck`) is the one installed on the host. I find this strange, since the system path should not exist on the container. How can I confirm that my `nvim` instance is attached to the container? Hmm yeah the experience with that is a bit bad. It is possible that nvim installation is just taking a while and you aren't yet attached. Generally, I guess it is easiest to try running some shell commands from nvim to confirm if you are in the container (e.g. `:!hostname`, or `!ls /`).
Sign in to join this conversation.
No Branch/Tag specified
main
feature/netman-integration
improvement/container-api
0.2.0
0.1.1
0.1.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
esensar/nvim-dev-container#149
Reference in a new issue
esensar/nvim-dev-container
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?