Add `devcontainer` configuration for codespace usage?

[coatless]

I've noticed the recent addition of the Dockerfile for building webR. Would you be open to the idea of a pull request that introduces a devcontainer configuration utilizing this Dockerfile?

By doing this, we could provide users with the ability to explore and work within Codespaces more easily, whether it's to compile their packages or simply to lower the barriers for contributing to the webr project. For further information on Codespaces, please refer to this link.

I'm already using Devcontainers and Codespaces for developing Quarto extensions, as showcased in this repository.

[georgestagg]

Sure, that sounds like a useful addition.

[coatless]

An update of sorts...

Building a container directly on source takes too long due to compilation in libs/ causing the codespace to "timeout", c.f. [1]. To address this, I'm aiming to use a pre-compiled container via the project's GitHub container repository. This approach yields a much more acceptable 2-minute launch time with a 3-minute compile time of old artifacts if using make at the top level of the repo.

So, what I've done here is I've opted to pick a container stored on GitHub's container repository, e.g:

https://github.com/r-wasm/webr/pkgs/container/webr

To generalize, I've set an ARG of VARIANT that is passed into a Dockerfile to select the container. This parameter takes main (current commit on repo), latest (current release tag), v0.y.z (a tagged release)

ghcr.io/r-wasm/webr:VARIANT

From there, I mount the /opt/webr/ folder as the default workspace folder. We further enable a few useful VS code extensions for development (note, my account was signed in on the video; so more were enabled.)

Though, this approach has a few downsides that I still need to rectify:

1. The .git configuration under /opt/webr defaults to the main r-wasm/webr repository instead of the forked version.
   • I can modify this by replacing the .git folder in /opt/webr with the workspace folder's .git and running a git pull on launch.
   • An alternative approach here would be to map the artifacts when running under the docker container to /opt/webr-artifacts.
2. Two sources are being copied into the codespace (the main repo and the forked repo) causing the size to be doubled.
   • The main repo is an artifact from the build process under /opt/webr and the forked repo comes from mounting into the codespace under /workspaces/webr.
   • I don't think there's a good way to remove the duplication of sources at the moment.

An alternative would be adding container layers to uncouple how much compilation is required from scratch. For example, there could be a base layer with the new llvm tooling, a dependency layer with all libs/ compiled, an R layer with a compiled version of R built, and, then, a layer that compiles webR.

Sample workflow with the container:

https://github.com/r-wasm/webr/assets/833642/cd6e2ddf-66b1-4a3b-b7d5-ec2fd081ec18

You can see the environment in a codespace by clicking on:

.devcontainer configuration information for the codespace can be viewed here:

https://github.com/coatless-quarto-webr/webr/tree/main/.devcontainer

[1]: