You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Adam Kocoloski <ko...@apache.org> on 2021/01/18 01:19:23 UTC
[DISCUSS] VS Code dev container?
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
Re: [DISCUSS] VS Code dev container?
Posted by Bessenyei Balázs Donát <be...@apache.org>.
I'm not a VS Code user, but I like the idea a lot!
For this change to lower the bar for new contributors, I think it
would be the best to have the change in-tree with a few lines of
description in the Readme.
One additional benefit I haven't seen mentioned would be the
Codespaces [1] integration. That should help us lower the bar even
further.
Donat
[1]: https://github.com/features/codespaces
On Mon, Jan 18, 2021 at 2:19 AM Adam Kocoloski <ko...@apache.org> wrote:
>
> 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
>
>
Re: [DISCUSS] VS Code dev container?
Posted by Adam Kocoloski <ko...@apache.org>.
Great, thanks for all the quick feedback. I’ve issued a PR against 3.x including the SM_VSN inheritance:
https://github.com/apache/couchdb/pull/3336 <https://github.com/apache/couchdb/pull/3336>
Donat, good call on the Codespaces option. Honestly I had glossed over the references to Codespaces when reading through the VS Code reference material on this feature, but it looks quite nice. I mentioned it and linked to the marketing page in the README-DEV file. I haven’t signed up for the Beta myself, but as far as I know everything I added is already Codespaces-compatible.
The one other thing I added is a very basic erlang_ls.config file to the root of the project, as without any config at all the language server fails to find the various header files that we pull in across applications using `-include_lib` and throws up all sorts of compilation errors. It’d be nice if erlang_ls supported a richer config system with multiple files so this wouldn’t clash with more customized files that I anticipate some of us have in place, but I don’t see how to do that from a cursory glance at the documentation. Cheers,
Adam
> On Jan 18, 2021, at 6:23 AM, Nick North <no...@gmail.com> wrote:
>
> I don't follow CouchDB much now, but I do use VS Code all the time, and
> have to bring new users on board with it. Docker and dev containers are
> very nice technologies for reducing VS Code start-up costs to almost zero,
> so this seems like a great plan, and I'd be in favour of anything that
> reduces friction, like the $SM_VSN override.
>
> Nick
>
> On Mon, 18 Jan 2021 at 11:09, Jan Lehnardt <ja...@apache.org> wrote:
>
>> I like this initiative and I have no objections to a $SM_VSN override.
>>
>> Best
>> Jan
>> —
>>
>>> On 18. Jan 2021, at 02:19, Adam Kocoloski <ko...@apache.org> wrote:
>>>
>>> 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
>>>
>>>
>>
>>
Re: [DISCUSS] VS Code dev container?
Posted by Nick North <no...@gmail.com>.
I don't follow CouchDB much now, but I do use VS Code all the time, and
have to bring new users on board with it. Docker and dev containers are
very nice technologies for reducing VS Code start-up costs to almost zero,
so this seems like a great plan, and I'd be in favour of anything that
reduces friction, like the $SM_VSN override.
Nick
On Mon, 18 Jan 2021 at 11:09, Jan Lehnardt <ja...@apache.org> wrote:
> I like this initiative and I have no objections to a $SM_VSN override.
>
> Best
> Jan
> —
>
> > On 18. Jan 2021, at 02:19, Adam Kocoloski <ko...@apache.org> wrote:
> >
> > 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
> >
> >
>
>
Re: [DISCUSS] VS Code dev container?
Posted by Jan Lehnardt <ja...@apache.org>.
I like this initiative and I have no objections to a $SM_VSN override.
Best
Jan
—
> On 18. Jan 2021, at 02:19, Adam Kocoloski <ko...@apache.org> wrote:
>
> 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
>
>