Hi hackers, On Sun, Aug 4, 2024 at 10:12 PM Andrew Dunstan <and...@dunslane.net> wrote: > > > On 2024-08-03 Sa 10:13 PM, Junwang Zhao wrote: > > On Sat, Aug 3, 2024 at 7:30 PM Andrew Dunstan <and...@dunslane.net> wrote: > >> > >> On 2024-08-02 Fr 2:45 PM, Peter Eisentraut wrote: > >>> On 01.08.24 23:38, Andrew Dunstan wrote: > >>>> 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. > >>> 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. > >>> > >> 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. > > 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. > > > That's kind of awful. Anyway, I think we don't need to do anything about > ignoring those. The user should simply add entries for them to > .git/info/exclude or their local global exclude file (I have > core.excludesfile = /home/andrew/.gitignore set.) > > I was eventually able to get it to work without using a symlink. > > > cheers > > > andrew > > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com >
I did some work on the **devcontainer config** today, hoping this can
address some of the concerns raised on this thread.
1. I created a separate git repo named **Unofficial devcontainer
config for Postgres**[1].
2. The usage is quite simple, clone the repo directly into postgres's tree root,
and reopen in DevContainer (See REAME in [1] if you are interested).
3. Using Tristan's vscode code extension postgres-hacker as the formatter,
pgindent will be called on file save, I found this quite convenient.
4. Remove the git settings, Dev container copies the global
~/.gitconfig into the container
by default, so normally it is not necessary to add extra git aliases.
What I haven't addressed is that the repo still uses specific local
paths, I think
this is ok since the code is not going into the core.
One thing I want to ask is, is there any objection to adding the
.devcontainer and .vscode to the .gitignore file?
There are *.vcproj and pgsql.sln in .gitignore, so I guess it's ok to add
.devcontainer and .vscode?
[1]: https://github.com/pghacking/.devcontainer
--
Regards
Junwang Zhao
v1-0001-add-.devcontainer-and-.vscode-to-.gitignore.patch
Description: Binary data
