public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrew Dunstan <[email protected]>
To: Junwang Zhao <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Subject: Re: Official devcontainer config
Date: Sun, 4 Aug 2024 10:12:29 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEG8a3L6Bhk=6p9k7REG193Wfp_Sxfo3SjAwuyG10Z04dWCTdg@mail.gmail.com>
References: <CAEG8a3K_mZsBZ60smh4FM4Dk9cazAUmM72iXdFKEHgthZnaHcw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAEG8a3L6Bhk=6p9k7REG193Wfp_Sxfo3SjAwuyG10Z04dWCTdg@mail.gmail.com>


On 2024-08-03 Sa 10:13 PM, Junwang Zhao wrote:
> On Sat, Aug 3, 2024 at 7:30 PM Andrew Dunstan <[email protected]> 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

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Official devcontainer config
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox