Add devcontainer #3637
Add devcontainer #3637
Conversation
There was a problem hiding this comment.
@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 😄
| @@ -0,0 +1,9 @@ | |||
| # Default image contents: https://hub.docker.com/r/mlpack/jenkins-amd64-debian | |||
There was a problem hiding this comment.
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.
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)
There was a problem hiding this comment.
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.
@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.
@rcurtin I'll take care of it later today in a PR over in the mlpack/jenkins-conf repository.
There was a problem hiding this comment.
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.
|
|
||
| // 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 mlpack or jenkins was created, we probably want root.
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
|
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! 👍 |
|
The underlying docker image was updated and now has support for C++/Python/R Bindings to be built. I left out Julia and Go as I'm not familiar with them. 
I suppose the next part is increasing the speed of the build process. |
|
Looking good to me---a couple questions:
If you're happy with this, I'm happy to merge it, it certainly seems like everything works correctly. The build process is unfortunately always going to be pretty slow... maybe there are some improvements that could be made, but it would be difficult to improve mlpack compilation speed in general. |
|
After. With mlpack/jenkins-conf#30, the image must be uploaded onto the mlpack org's dockerhub account. From there, we can switch it from With that in mind, we may want to remove the VARIANT approach as a single codespace image exists. For documentation, how about:
For prose on the cost, maybe:
|
|
Everything you proposed looks great to me. 👍 Sorry it took so long to get back to this! It was a busy summer for me and I am glad it is over... |
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
jenkinspassword. (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