Re: Official devcontainer config

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Junwang Zhao <zhjwpku(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Andrey Borodin <amborodin86(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Subject: Re: Official devcontainer config
Date: 2024-08-01 21:38:17
Message-ID: 57c12c52-123c-4a13-a258-02639473fa17@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2024-08-01 Th 10:56 AM, Junwang Zhao wrote:
> 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
>

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-08-01 21:41:18 Re: optimizing pg_upgrade's once-in-each-database steps
Previous Message Andrew Dunstan 2024-08-01 21:19:43 Re: Improving tracking/processing of buildfarm test failures