From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
	by lore.proxmox.com (Postfix) with ESMTPS id 5E4391FF16F
	for <inbox@lore.proxmox.com>; Thu, 30 Jan 2025 10:12:20 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id D76B0B72F;
	Thu, 30 Jan 2025 10:12:15 +0100 (CET)
Message-ID: <f70a0113-a09e-4590-ad9a-beb1b67ef3be@proxmox.com>
Date: Thu, 30 Jan 2025 10:11:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20241205140721.207021-1-d.kral@proxmox.com>
 <f7b6603b-4423-464e-8fc2-0df5ed956650@proxmox.com>
Content-Language: en-US
From: Daniel Kral <d.kral@proxmox.com>
In-Reply-To: <f7b6603b-4423-464e-8fc2-0df5ed956650@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.011 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [RFC PATCH installer] fix #5973: auto: first boot:
 allow snake- and kebabcased property names
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>

On 1/28/25 15:38, Thomas Lamprecht wrote:
> This is a bit worded like that behavior would be a regression, but it
> isn't AFAICT as this was always kebab-case from when being added in
> commit 6526662 ("fix #5579: auto-installer: add optional first-boot hook
> script"); or am I overlooking something?

I'm sorry that the commit message came across like this, I didn't intend 
to word it as a regression, but I can see why it did. I wasn't aware 
that we prefer kebab-case for newer property names in the answer file 
and I'll keep that in mind for future patches.

> But we prefer kebab-case for any public API/CLI parameter for modern code;
> so shouldn't we rather to the opposite, transform all other (de)serializable
> configs to use kebab-case with backward-compat aliases for the cases it
> matters?

I also like that solution and that is more in line with the motivation 
behind the patch. I could queue up a patch for the next ISO release, so 
that it's indifferent to the user whether they write the config 
parameter names in their answer files in the old snake case or new 
kebab-case format.

I'd prefer a single serde attribute for that rather than rename_all + 
alias at every property, if that's possible in a few lines, as it would 
be cleaner and we don't have to look at every property whether it's 
missing a alias attribute or not.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel