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

Confused about main use cases #98

Open
opened 2023年12月05日 00:32:10 +01:00 by ryanmsnyder · 2 comments

Thank you for the development of this plugin. While trying to get it working, I've read through quite a few open and closed issues that have made me wonder if I'm understanding the main use case for this plugin. I hope you can help me understand, as I think nvim-dev-container can help me achieve the workflow I'm going for.

My desired workflow is to run NeoVim (with all of the necessary LSP/Debugging tools I use) within a container. I'd like to attach to the running instance of NeoVim from my local terminal so that I can edit/debug within my container.

In the README, you mention that the "plugin is inspired by jamestthompson3/nvim-remote-containers, but aims to enable having neovim embedded in docker container."

My questions are:

  1. Is the above goal of the plugin still to have NeoVim embedded in the devcontainer? I came across issue #30, which makes it sound like you're having to move away from that feature for technical reasons (but maybe I'm misunderstanding the main goal of that specific issue).

  2. As mentioned in my first question above, if the main use case is no longer to attach to a container running NeoVim, how does this plugin differ from jamestthompson3/nvim-remote-containers?

  3. Does this plugin use the somewhat new client-server functionality in NeoVim?

  4. Does this plugin completely follow the specs of VSCode's devcontainer.json. For example, I'm trying to start a container without automatically running the command specified in my Dockerfile by including overrideCommand: true in my .devcontainer.json file but when executing :DevcontainerStart, it executes the Dockerfile CMD.

.devcontainer.json

{
 "name": "devcontainer-test",
 "build": {
 "dockerfile": "Dockerfile"
 },
 "service": "app",
 "dockerComposeFile": "docker-compose.yml",
 "overrideCommand": true
}

docker-compose.yml

version:"3.6"services:app:build:.

Dockerfile

FROM python:3.12
WORKDIR /app
COPY . /app
RUN pip install --no-cache-dir -r requirements.txt
CMD ["python", "./main.py"]

Thanks in advance. I'm somewhat new to Docker and even newer to devcontainers so I apologize if I'm missing something obvious in my setup.

Thank you for the development of this plugin. While trying to get it working, I've read through quite a few open and closed issues that have made me wonder if I'm understanding the main use case for this plugin. I hope you can help me understand, as I think `nvim-dev-container` can help me achieve the workflow I'm going for. My desired workflow is to run NeoVim (with all of the necessary LSP/Debugging tools I use) within a container. I'd like to attach to the running instance of NeoVim from my local terminal so that I can edit/debug within my container. In the README, you mention that the "plugin is inspired by [jamestthompson3/nvim-remote-containers](https://github.com/jamestthompson3/nvim-remote-containers), but aims to enable having neovim embedded in docker container." My questions are: 1. Is the above goal of the plugin still to have NeoVim embedded in the devcontainer? I came across [issue #30](https://codeberg.org/esensar/nvim-dev-container/issues/30), which makes it sound like you're having to move away from that feature for technical reasons (but maybe I'm misunderstanding the main goal of that specific issue). 2. As mentioned in my first question above, if the main use case is no longer to attach to a container running NeoVim, how does this plugin differ from [jamestthompson3/nvim-remote-containers](https://github.com/jamestthompson3/nvim-remote-containers)? 3. Does this plugin use the somewhat new [client-server](https://neovim.io/doc/user/remote.html) functionality in NeoVim? 4. Does this plugin completely follow the specs of VSCode's `devcontainer.json`. For example, I'm trying to start a container without automatically running the command specified in my `Dockerfile` by including `overrideCommand: true` in my `.devcontainer.json` file but when executing `:DevcontainerStart`, it executes the `Dockerfile` CMD. .devcontainer.json ```json { "name": "devcontainer-test", "build": { "dockerfile": "Dockerfile" }, "service": "app", "dockerComposeFile": "docker-compose.yml", "overrideCommand": true } ``` docker-compose.yml ```yml version: "3.6" services: app: build: . ``` Dockerfile ``` FROM python:3.12 WORKDIR /app COPY . /app RUN pip install --no-cache-dir -r requirements.txt CMD ["python", "./main.py"] ``` Thanks in advance. I'm somewhat new to Docker and even newer to devcontainers so I apologize if I'm missing something obvious in my setup.

In reference to question 4 above, I've just realized that "overrideCommand": true is the default for devcontainers in VSCode and that VSCode will execute /bin/sh -c "while sleep 1000; do :; done" to keep the container alive. Is that the same case with nvim-dev-container?

In reference to question 4 above, I've just realized that `"overrideCommand": true` is the default for devcontainers in VSCode and that VSCode will execute `/bin/sh -c "while sleep 1000; do :; done"` to keep the container alive. Is that the same case with `nvim-dev-container`?

Hi!
Thank you for trying out the plugin and reporting this issue.

  1. This is still the goal of the plugin, although it is no longer the main goal, since currently without issue #30 the experience is not ideal. It is still possible to do with DevcontainerAttach command, but it will result in nested neovim instance.

  2. I haven't checked the other plugin in a while, but I remember when I tried it before writing my own plugin, it didn't offer much capabilities. It was possible to start the container and that was it. Any other interaction after that was not possible. My goal with this plugin was primarily to enable running neovim in that container, but also generally improve experience related to devcontainers and get it close to VSCode where it makes sense.

What it offers right now is more control over containers, support for podman (full support, mostly tested with this) and devcontainer CLI (very limited, it disables many of the features of this plugin), DevcontainerAttach command which can embed neovim in the container (and manage installation for containers with apt package manager - it is possible to customize this via configuration to cover other package managers), but it can also run and attach to any other command, meaning DevcontainerAttach sh enables you to inspect container using a shell.

  1. This was the goal of issue #30, but it is not possible to attach to a server from a current neovim session, so I put that issue on hold for now.

  2. That was implemented in one of more recent updates to the plugin. That should behave the same as VSCode. There might be a bug there though, so if you could share some more information on that, that would be very helpful!

Hi! Thank you for trying out the plugin and reporting this issue. 1. This is still the goal of the plugin, although it is no longer the main goal, since currently without [issue #30](https://codeberg.org/esensar/nvim-dev-container/issues/30) the experience is not ideal. It is still possible to do with `DevcontainerAttach` command, but it will result in nested neovim instance. 2. I haven't checked the other plugin in a while, but I remember when I tried it before writing my own plugin, it didn't offer much capabilities. It was possible to start the container and that was it. Any other interaction after that was not possible. My goal with this plugin was primarily to enable running neovim in that container, but also generally improve experience related to devcontainers and get it close to VSCode where it makes sense. What it offers right now is more control over containers, support for `podman` (full support, mostly tested with this) and `devcontainer` CLI (very limited, it disables many of the features of this plugin), `DevcontainerAttach` command which can embed neovim in the container (and manage installation for containers with `apt` package manager - it is possible to customize this via configuration to cover other package managers), but it can also run and attach to any other command, meaning `DevcontainerAttach sh` enables you to inspect container using a shell. 3. This was the goal of [issue #30](https://codeberg.org/esensar/nvim-dev-container/issues/30), but it is not possible to attach to a server from a current neovim session, so I put that issue on hold for now. 4. That was implemented in one of more recent updates to the plugin. That should behave the same as VSCode. There might be a bug there though, so if you could share some more information on that, that would be very helpful!
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#98
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?