Add devcontainer #3637
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| # Default image contents: https://hub.docker.com/r/mlpack/jenkins-amd64-debian | ||
| # Choose different variants available at: https://hub.docker.com/u/mlpack | ||
| ARG VARIANT=jenkins-amd64-debian | ||
| FROM mlpack/${VARIANT} | ||
|
|
||
| # Additional options here... | ||
| # RUN apt update && apt upgrade -y | ||
|
|
||
| # and so on... | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| { | ||
| "name": "mlpack C++ Dev Container", | ||
| "build": { | ||
| "dockerfile": "Dockerfile", | ||
| // Update 'VARIANT' to pick a new mlpack base image from | ||
| // https://hub.docker.com/u/mlpack | ||
| "args": { "VARIANT": "jenkins-amd64-debian" } | ||
| }, | ||
| // Configure tool-specific properties. | ||
| "customizations": { | ||
| // Configure properties specific to VS Code. | ||
| "vscode": { | ||
| "settings": {}, | ||
| "extensions": [ | ||
| "twxs.cmake", | ||
| "ms-vscode.cpptools", | ||
| "ms-vscode.cmake-tools", | ||
| "llvm-vs-code-extensions.vscode-clangd" | ||
| ] | ||
| } | ||
| } | ||
|
|
||
| // Switch to using root as a remote user | ||
| // details: https://aka.ms/dev-containers-non-root. | ||
| // "remoteUser": "root" | ||
|
There was a problem hiding this comment. 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.) There was a problem hiding this comment. For simplicity and to avoid folks wondering where user |
||
| } | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal is for a container that could be used for immediate development on
mlpackitself 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/mlpackis 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
devcontainerimage to lower storage (the base image is free for storage on GitHub and includes a lot of languages)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@coatless let me know what you think on this point, I'm happy to help with a new Dockerfile. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rcurtin I'll take care of it later today in a PR over in the
mlpack/jenkins-confrepository.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.