Add devcontainer

[coatless]

So, this adds a devcontainer image that has a few choice C++ extensions enabled (but not configured) for VS Code.

You can check it out on my forked repo here:

The video next shows creating the codespace from scratch and running cmake. It stops just before the build install step as I didn't see jenkins password. (For that reason, maybe we should opt for a different base image?) In total, the runtime is ~2.5 minutes.

launch-mlpack-codespace.mp4

Close #3632

[rcurtin]

@coatless this is a nice addition! On our side I think we can clean up the base Docker images and I can make changes there and push to Dockerhub as needed, but I have a handful of questions.

Note that I have never used Codespaces, hadn't heard of devcontainer.json before about two days ago, and otherwise have little idea what is going on. So if my comments are way off base or miss the point, please tell me so 😄

[rcurtin]

Maybe the mlpack/mlpack image would be the better one to use?
https://hub.docker.com/r/mlpack/mlpack

I guess one question is, is the goal to have a container with mlpack already built and available, so that the user can develop applications that use mlpack? Or is the goal to have a container that has mlpack's dependencies, so that a user can develop mlpack itself and submit PRs to the project?

In either case, it's trivial to add a new Dockerfile to here that we can just use directly.

[coatless]

The goal is for a container that could be used for immediate development onmlpack itself with a low storage cost. That is, we could say to the wave of GSOC students, here's how you can quickly jump in and work on a PR.

Using mlpack/mlpack is probably even better for hitting both use cases.

Though, if you're okay with adding in a new Docker image, we may want to create a custom docker image that is based on the default devcontainer image to lower storage (the base image is free for storage on GitHub and includes a lot of languages)

[rcurtin]

Absolutely, piece of cake to add another image. Here's the existing Dockerfile for mlpack/mlpack; do you want to adapt that? Or I can take a shot at it if you like. Once we have something ready I can push it to Dockerhub.

I think it might be a good idea to not install mlpack in whatever container we use; I'm imagining a situation where the user modifies some core mlpack code (in wherever the mlpack source code is checked out), but now that code differs from what's in /usr/include/ (the installed version) and strange linking or behavior issues happen when trying to use mlpack.

[rcurtin]

@coatless let me know what you think on this point, I'm happy to help with a new Dockerfile. 👍

[coatless]

@rcurtin I'll take care of it later today in a PR over in the mlpack/jenkins-conf repository.

[coatless]

Let's take the discussion on the Universal base over to: mlpack/jenkins-conf#30

Short gist: I need to lobotomize the container to build it.

[rcurtin]

What is the preference here? I don't know about devcontainers, but should we be using the root user in the container? (Easy enough to adapt the relevant dockerfiles if so.)

[coatless]

For simplicity and to avoid folks wondering where user mlpack or jenkins was created, we probably want root.

[mlpack-bot]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! 👍