Hey,

That is one of the standard ways to use this plugin. It should be
supported without any tinkering. Please look at https://containers.dev/implementors/json_reference/#image-specific
for reference on `devcontainer.json` config regarding this (specifically
`build.dockerfile` and `build.context`).

On Sat Sep 7, 2024 at 12:52 PM CEST, Mike Crowe wrote:
> Hey, what's the process for using this without a docker-compose.yml
> file?  I simply have a devcontainer/devcontainer.json and Dockerfile


-- 
Ensar Sarajčić

I have finally implemented this request. I had to make a minor change in
the way config files are found in the actual plugin, but the rest of
this feature can be controlled by configuration. I have added an example
configuration in the wiki:

https://codeberg.org/esensar/nvim-dev-container/wiki/Recipes#support-for-multiple-devcontainer-configs

Let me know if that works for you. You can also further customize it if
you prefer different behavior.
-- 
Ensar Sarajčić
w: www.ensarsarajcic.com

Thank you! I have added a comment on the issue on codeberg, for
visibility.
-- 
Ensar Sarajčić
w: www.ensarsarajcic.com

On Tue Apr 23, 2024 at 6:48 AM CEST, Daniel Gray wrote:
> I'm not sure how this should be implemented, but I'd appreciate it if
> you found the time :) I'm sure it would be useful to others as well.
>

I will get to it these days. I think it shouldn't be difficult.

>
> Sure. I attached the log.

Thanks for the log. It seems the issue was in starting of the container.
Thanks for reporting this, since it seems that there was an issue
starting containers that had an entrypoint defined. In these cases
command was not properly overriden (in your case the container has

On Sun Apr 14, 2024 at 6:48 AM CEST, Daniel Gray wrote:
> Hi,
>
> I'm trying to use this with our project, but have a few issues. Both
> configs work fine in Visual Studio Code.
>
> 1) We have two devcontainer.json files, one which uses the public and
>    one for our team. Is there a way to control which decontainer.json
>    file is used?
>
>    - https://github.com/privacyguides/privacyguides.org/blob/main/.devcontainer/devcontainer.json
>    - https://github.com/privacyguides/privacyguides.org/blob/main/.devcontainer/team/devcontainer.json
>
>    If I just do :DevcontainerStart it builds the first

On Wed Feb 7, 2024 at 5:15 PM CET, Reggie Cushing wrote:
> Hi,
>    First of all nice plugin!! Going through the code I’m wondering what is the purpose of the target argument in e.g. DevcontainerExec command when you have more than one argument. The reason I ask is that it took me a while to understand why DevcontainerExec cargo run was failing.

Hi! Thank you!
It takes container as target. The default is "devcontainer", meaning the
container defined in `.devcontainer` file, but it can also take "latest"
to executo on latest used container and it can also take any other
container (and it can be autocompleted to see the whole list). In your
case, `DevcontainerExec devcontainer cargo run` should have worked.

I understand this is a bit weird to use. If you have suggestions on how
the command could look like (maybe like a `--target` option), I would
gladly make it a bit better.

On Thu Nov 23, 2023 at 11:03 AM CET, Linus Marton wrote:
> Hi!

Hi!

Thanks for trying the plugin and reaching out!

> I can run `:DevcontainerStart` and `:DevcontainerAttach` successfully. I get a tab with another neovim which works. But, can I somehow get a terminal sesson that is running inside the container? If I run `:terminal` I get a terminal, but it's not running inside the container.

If you are running one of the more recent versions, you should be able
to pass a command to `:DevcontainerAttach` - by default it is `nvim`,
but by running `:DevcontainerAttach sh` you should be able to get a
terminal session.

I have now added this feature, it is available on `main` branch.

Custom commands can be defined in `nvim_installation_commands_provider`
function, which can be provided to the `setup` function.

You can check out the default implementation in https://codeberg.org/esensar/nvim-dev-container/src/commit/415332f479ca873147f489fcf3cfb5a83fbed0c1/lua/devcontainer/config.lua#L54
-- 
Ensar Sarajčić
w: www.ensarsarajcic.com

On Tue Oct 10, 2023 at 4:40 PM CEST, John Krueger wrote:
> When I'm prompted to install neovim on the container, it fails. I'm having to build from source on my container because there's no recent package for my chosen linux. Is there a way to define my own custom install script to run when prompted? 
>
> It's probably already in the settings and I just wasn't savvy enough to pick up where I need to put it. If this functionality doesn't exist already, it's not a huge deal and I'll probably  end up taking care of it on the docker side so neovim is pre-installed.

Unfortunately, you are not missing it. Seems I forgot to update it when
I was refactoring that part of the functionality. Previously it was done
using temporary `Dockerfile` and you can see that configuration option
available right now, but it is not doing anything. I am working on
removing it and providing a separate configuration option to provide
your own commands for installing neovim.

>
> Thanks in advance for any help this is a great tool you've built!

On Tue Aug 15, 2023 at 4:04 PM CEST, Michal Tichák wrote:
> Hello,
> I have a question: Why should I use dev-container plugin? The reason why I am asking is that I love nvim, but lately I had to move from linux x86/64 to Mac ARM, which means that I need to use docker for a lot of work. When I found your plugin I was really happy because I thought that I will not have to move VS code, whose dev containers work really well (I know that it is created byt Microsoft, so the situation is not really comparable :) ). 

Hello! Thank you for your question.
The plugin is still being developed, so I am hoping it will only get
better with time, but right now, it's main purpose is making it easier
to work with containers, especially with containers defined in
devcontainer format (the one VSCode uses).

>
> But after trying to run your plugin I got the impression that I get the similar functionality if I directly run docker image with mounted settings, as I need to install the neovim to the every image imageI need to use. So if I do stuff on multiple images, I need to get nvim inside every image. Moreover I guess that I need to install every plugin every time I start developing. So what is the advantage over creating the images with with neovim already prepared?

Yes, unfortunately, that is correct. Recently I have been making changes