vscode container-based development environment ("devcontainer")

[phrohdoh]

from https://code.visualstudio.com/docs/remote/containers

The Visual Studio Code Remote - Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code's full feature set.

see https://www.youtube.com/watch?v=Uvf2FVS1F8k for a quick (~5 1/2 minute) video explanation
vscode remote development extension pack: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack

GitHub Codespaces is an application of this that provides managed remote dev envs (which are configurable via dotfiles)
https://github.com/features/codespaces & https://code.visualstudio.com/docs/remote/remote-overview#_github-codespaces

---

vscode (and related/derived tech) user experience would be:

1. open repo root (whether remote (gh codespaces) or local git clone) directory
2. container created (as necessary) from configured Dockerfile -- node, jvm, lein, etc installed (user waiting / watching progress)
3. vscode/editor ready to be used on containerized workspace

having the relevant configuration files in-tree would provide the experience for vscode (and related tech) users to being able to open a containerized/remote workspace with athens cloned in, deps/tooling/etc installed, and still be able to use my extensions (i.e. themes, keybindings, ...) all without installing a particular, e.g. JVM, outside of a container (no "polluting" of your local system)

[phrohdoh]

I have a work-in-progress branch where I am exploring this.
Please take a look if this is of any interest to you!

[tangjeff0]

Why not just use a native VS Code networked tool like Foam or Dendron :P

[phrohdoh]

This request concerns development of Athens.

[lswank]

@tangjeff0, the key here is to be able to clone the project in VS Code with everything needed for development already built-in / prepped. Consider it an expanded version of the Dockerfile in the root of the project, but with VS Code-specific hints for Plugins and other useful tools.

My question to @phrohdoh is this: Won't this create a duplication of Dockerfiles? I would be more concerned about those two files getting away from one another. Is it possible to do this with the Dockerfile that is already in the root of the project?

[tangjeff0]

Ah I didn't read this closely. It's essentially a Docker alternative. VS Code is so crazy these days! Thanks for clarifying @lswank

[lswank]

It might be helpful to think of it not even as a Docker alternative, but as Docker with a few VS Code extras. @tangjeff0 I am happy to do a screen share some day soon and show you how it works, but essentially this is how it goes.

• Clone the project. It's still got a Beautiful Dockerfile which being all of the benefits that you are used to
• Open in visual studio code.
• Suddenly, developer-recommended extensions populate the IDE.
• VSCode asks, "I noticed you have a Dockerfile. Should I automagically start it up?"

I think you ought to encourage this as long as the person who has created the branch can resolve the issue of duplicate work. The last thing we want are two Dockerfiles that are not synchronized.

Just my $0.02.


[phrohdoh]

The last thing we want are two Dockerfiles that are not synchronized.

I completely agree.
I think we'd want the base dockerfile to set up the environment only (not build/run/etc) which'd be used by VSCode, then could have another dockerfile for building which extends that base one (and knows nothing about vscode / a particular editor) and runs the build command(s).

Thoughts?