Hi folks, I don’t know how many of you use VS Code as your preferred editor, but I found myself setting up a new laptop recently and I thought I’d try out their support for containerized development environments[1] to get my CouchDB rig up and running. I started with the 3.x branch this weekend and came up with the following:
https://github.com/apache/couchdb/compare/3.x...3.x-devcontainer With this .devcontainer folder a VS Code user who clones CouchDB gets a prompt to mount the codebase inside a container with all the dependencies required to build CouchDB, run the test suite, build the docs, etc. The source code lives outside the container, and the data files produced by a dev cluster do as well. I think this could help lower the bar for new contributors to get involved in the project. Some additional details: - The .devcontainer also installs the Erlang Language Server extension into the container, so the setup comes complete with syntax coloring, auto-complete, module outlines, etc. - I used an official Elixir image as the base for this image (given that we need Elixir for the test suite these days). Elixir builds off the the official Erlang images, which in turn are based on Debian. I initially tried to use the images we maintain for our CI setup but found some challenges getting those to work with Erlang LS out of the box and this ended up being a simpler route. Open to discussion on this one. - I defaulted to Erlang 22 / Debian Buster and SpiderMonkey 60 installed from Debian. This means a user needs to add `—spidermonkey-version 60` during ./configure. I expect this will add a little friction for new users. Would it be OK to have configure inherit $SM_VSN from the external environment in addition to the command-line to smooth this over? I‘m polishing up another devcontainer for the main branch that uses Docker Compose to run FoundationDB using the official FDB image alongside the CouchDB layer, but I wanted to take the pulse of the folks here to see if these container configs make sense in-tree and whether there are opinions about how they should be done. I intentionally opted for simplicity on this front rather than trying to reuse too much of our CI or production image code. Cheers, Adam [1]: https://code.visualstudio.com/docs/remote/containers
