Updated devcontainer definition

[stemann]

Ensuring:

• Running as non-root user to make tests pass, notably Base.runtests("file") - by basing container on mcr.microsoft.com/devcontainers/cpp.
• Availability of gdb.
• Caching when building/creating container by using build stages (and devcontainer features) instead of onCreateCommand.

Also added the Makefile Tools extension (and the C/C++ Extension Pack to quiet vscode/codespaces).

[giordano]

My understanding is that Dockerfiles were deprecated, that's why #57006 removed it.

[stemann]

I did notice #57006 - is there any documentation for Dockerfile being deprecated for devcontainer definitions? I can't seem to find it.

[stemann]

@M-PERSIC any comments on this?

[M-PERSIC]

Dockerfiles aren't deprecated for devcontainers, in this case they were unneeded because we could specify the entire development environment via devcontainer.json alone. If there is some future development requirement that can only be integrated via a custom container image, then we can simply add a Dockerfile again.

Some additional comments:

• Couldn't we add a non-root user for testing instead? The --privileged flag is set, however this does not dictate which user actually runs the processes inside the container.
• Docker will cache the image locally after the first pull, and features act as their own layers for caching (see Implementation Notes). Lifecycle commands aren't seemingly cached, however I would argue that it is okay to ignore cache in this instance because:

1. It would be somewhat annoying to bring back the Dockerfile for a single RUN command
2. During development we may resort many times to a full rebuild of the devcontainer, which clears the cache anyway

• Based on the marketplace description, the only differences between the C/C++ extension and extension pack is the addition of themes and a CMake extension. We could probably just add the CMake extension separately (ms-vscode.cmake-tools) since the themes are not relevant for development purposes.
• makefile-tools does sound like an interesting addition, however based on the marketplace reviews it does seem to be a bit buggy. Could you confirm if it runs correctly with your setup?

[stemann]

I think it is much more important to have caching than whether there is a Dockerfile or not.

During development we may resort many times to a full rebuild of the devcontainer, which clears the cache anyway.

During development of the devcontainer, yes - then the cache might get invalidated. During development of Julia, no - the cache would not be invalidated. I would not prioritize development of the devcontainer.

I only added the C/C++ Extension Pack to quiet vscode/codespaces - in contrast to just having the ms-vscode.cpptools extension - to not have the first launch experience be a cascade of pop-ups (suggesting the C/C++ Extension Pack... Microsoft...).

makefile-tools works correctly, I think - I have been using it for a couple of months (but also using make from the terminal, of course) - haven't noticed any issues. At some point I got Intellisense for the Julia C code, I think, thanks to the Makefile Tools - not sure how to get it back... - it looks like the extension also makes it possible to launch a debugger running the selected target (e.g., default, i.e., usr/bin/julia).

[M-PERSIC]

If that's the case, then adding back the Dockerfile is fine. Ideally we would enable codespace prebuilds for complete dev environment caching, but that's for a future discussion :)

Additional channels such as lts or nightly via the julia feature could be nice as well.

[stemann]

Bump (I would suggest to just have a reasonably lean install with the juliaup release channel (and not add lts and/or nightly channels).