Subject: Official devcontainer config

From: Junwang Zhao <[email-masked]>
Date: Thu, 1 Aug 2024 22:56:40 +0800

Stack Overflow 2024 developer survey[1] said VSCode
is the most used development environment.

In a PostgreSQL Hacker Mentoring discussion, we talked
about how to use vscode to debug and running postgres,
Andrey(ccd) has tons of tips for new developers, and
I post my daily used devcontainer config[2] , Jelte(ccd)
suggested that it might be a good idea we integrate the
config into postgres repo so that the barrier to entry for
new developers will be much lower.

**Note**

This is not intended to change the workflow of experienced
hackers, it is just hoping to make the life easier for
beginner developers.

**How to use**

Open VSCode Command Palette(cmd/ctrl + shift + p),
search devcontainer, then choose something like
`Dev containers: Rebuild and Reopen in Container`, you are
good to go.

**About the patch**

devcontainer.json:

The .devcontainer/devcontainer.json is the entry point for
VSCode to *open folder to develop in a container*, it will build
the docker image for the first time you open in container,
this will take some time.

There are some parameters(runArgs) for running the container,
we need some settings and privileges to run perf or generate
core dumps.

It has a mount point mapping the hosts $HOME/freedom
to container's /opt/freedom, I chose the name *freedom*
because the container is kind of a jail.

It also installed some vscode extensions and did some
customizations.

After diving into the container, the postCreateCommand.sh
will be automatically called, it will do some configurations
like git, perf, .vscode, core_pattern, etc. It also downloads
michaelpq's pg_plugins and FlameGraph.

Dockerfile:

It is based on debian bookworm, it installed dependencies
to build postgres, also IPC::Run to run TAP tests I guess.

It also has a .gdbinit to break elog.c:errfinish for elevel 21,
this will make the debugging easier why error is logged.

gdbpg.py is adapted from https://github.com/tvondra/gdbpg,
I think putting it here will make it evolve as time goes.

tasks.json:

This is kind of like a bookkeeping for developers, it has
the following commands:

- meson debug setup
- meson release setup
- ninja build
- regression tests
- ninja install
- init cluster
- start cluster
- stop cluster
- install pg_bsd_indent
- pgindent
- apply patch
- generate flamegraph

launch.json:

It has one configuration that makes it possible to attach
to one process(e.g. postgres backend) and debug
with vscode.

PFA and please give it a try if you are a VSCode user.

[1]: https://survey.stackoverflow.co/2024/technology#1-integrated-development-environment
[2]: https://github.com/atomicdb/devcontainer/tree/main/postgres

--
Regards
Junwang Zhao

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 1 Aug 2024 17:38:17 -0400

> [2]: https://github.com/atomicdb/devcontainer/tree/main/postgres

Not totally opposed, and I will probably give it a try very soon, but 
I'm wondering if this really needs to go in the core repo. We've 
generally shied away from doing much in the way of editor / devenv 
support, trying to be fairly agnostic. It's true we carry .dir-locals.el 
and .editorconfig, so that's not entirely true, but those are really 
just about supporting our indentation etc. standards.

Also, might it not be better for this to be carried in a separate repo 
maintained by people using vscode? I don't know how may committers do. 
Maybe lots do, and I'm just a dinosaur. If vscode really needs 
.devcontainer to live in the code root, maybe it could be symlinked. 
Another reason not carry the code ourselves is that it will make it less 
convenient for people who want to customize it.

Without having tried it, looks like a nice effort though. Well done.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 2 Aug 2024 20:45:20 +0200

> just about supporting our indentation etc. standards.

Yeah, the editor support in the tree ought to be minimal and factual, 
based on coding standards and widely recognized best practices, not a 
collection of one person's favorite aliases and scripts.  If the scripts 
are good, let's look at them and maybe put them under src/tools/ for 
everyone to use.  But a lot of this looks like it will requite active 
maintenance if output formats or node formats or build targets etc. 
change.  And other things require specific local paths.  That's fine for 
a local script or something, but not for a mainline tool that the 
community will need to maintain.

I suggest to start with a very minimal configuration. What are the 
settings that absolute everyone will need, maybe to set indentation 
style or something.

---

From: Andrew Dunstan <[email-masked]>
Date: Sat, 3 Aug 2024 07:30:08 -0400

On 2024-08-02 Fr 2:45 PM, Peter Eisentraut wrote:
>> support, trying to be fairly agnostic. It's true we carry 
>> .dir-locals.el and .editorconfig, so that's not entirely true, but 
>> those are really just about supporting our indentation etc. standards.
>
> collection of one person's favorite aliases and scripts.  If the 
> scripts are good, let's look at them and maybe put them under 
> src/tools/ for everyone to use.  But a lot of this looks like it will 
> requite active maintenance if output formats or node formats or build 
> targets etc. change.  And other things require specific local paths.  
> That's fine for a local script or something, but not for a mainline 
> tool that the community will need to maintain.
>

I believe you can get VS Code to support editorconfig, so from that POV 
maybe we don't need to do anything.

I did try yesterday with the code from the OP's patch symlinked into my 
repo, but got an error with the Docker build, which kinda reinforces 
your point.

Your point about "one person's preferences" is well taken - some of the 
git aliases supplied  clash with mine.

cheers

andrew

---

From: Junwang Zhao <[email-masked]>
Date: Sun, 4 Aug 2024 10:02:55 +0800

> convenient for people who want to customize it.

Agree, if finally we make this into a separate repo, that can also
benefit new developers.

-- 
Regards
Junwang Zhao

---

From: Junwang Zhao <[email-masked]>
Date: Sun, 4 Aug 2024 10:13:49 +0800

> repo, but got an error with the Docker build, which kinda reinforces

The reason symlink does not work is that configure_vscode needs to copy
launch.json and tasks.json into .vscode, it has to be in the
WORKDIR/.devcontainer.

> git aliases supplied  clash with mine.

Yeah, I will remove that.

-- 
Regards
Junwang Zhao