From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id WB7oN3syw2EMtQAAgWs5BA (envelope-from ) for ; Wed, 22 Dec 2021 15:13:15 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id MJ+7M3syw2GIGwAA1q6Kng (envelope-from ) for ; Wed, 22 Dec 2021 14:13:15 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 960083437B for ; Wed, 22 Dec 2021 15:13:15 +0100 (CET) Received: from localhost ([::1]:34814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n02Mk-0004EG-NC for larch@yhetil.org; Wed, 22 Dec 2021 09:13:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n02Kq-0001hm-OM for guix-devel@gnu.org; Wed, 22 Dec 2021 09:11:16 -0500 Received: from mail2.fsfe.org ([213.95.165.55]:56560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n02Kd-0004tz-AI for guix-devel@gnu.org; Wed, 22 Dec 2021 09:11:08 -0500 From: Jelle Licht DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsfe.org; s=2021081301; t=1640182259; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zdF7SJ/T9w7Wd/dw+DlFO2jDXg/pPvzsUgpHgOpuDb8=; b=fKq2ewOiH8hduEoNgKDFFiqkwdqqB2Ga8XcSkwr90QCXlgbBo5WTzlrt1/DfkD0YwzMEKO fl3zOdFgyM6vrBGecZ/jkgIC5SJ8Bxcy1DFNato8dnE6q2jzHQIo6XyNoOYx/fjrB00wlg MjxXUArilEZPmE9xwsjQ9NtU6bo3MxQ= To: zimoun , Guix Devel Subject: Re: Convention for new =?utf-8?Q?=E2=80=9Cguix_style=E2=80=9C=3F?= In-Reply-To: <86bl18sscd.fsf@gmail.com> References: <86bl18sscd.fsf@gmail.com> Date: Wed, 22 Dec 2021 15:10:58 +0100 Message-ID: <86a6gsd91p.fsf@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=213.95.165.55; envelope-from=jlicht@fsfe.org; helo=mail2.fsfe.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640182395; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=zdF7SJ/T9w7Wd/dw+DlFO2jDXg/pPvzsUgpHgOpuDb8=; b=NjSXYX0fNGMQ5TJnArq8S7ffB3csltVqUme7i5AkaupMHpm7VfaVwillMgladZyLEQiCxF oTac70RgNVu0NW28IpeEuaW/cL7dV2aWZMEHiFkLG/YIPwgHrVqLvfeDIIKQJtDSRcoICi DFruQqwJjcowqEdel9iouIqHyWtUA+0EWMTFMdbQ2OusVytrxP3NPv8netjYBsa/oS+g4q v5LyRlfMnZadBHsVAroAkPq9Yg9VO3YNSv6nJFAZhjxlga5g1h5dUvOWiQvRwW3w/DNig5 t2PhYWatag8/E4F9p58T3bGKelgI1gFl95v6DpEpExFFYCZTjZv24/puxT/QQA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640182395; a=rsa-sha256; cv=none; b=Tkugdk7WBSkyJjiGytD7Z+mYMw1Z72BMyxMzzGheB5kuXExvTJXLBuIY7baJpqAa4E7yUL BGQDBKyP/mvBVNebpZ0IQe/WrVb10qd2Zi8wK5vLk0OkdhfMrgiWB+OGk/KdtMuX+dFBk7 T4Ejjam6VYEW4rLM31Bsy4F3oyreMUkyhc0u7eTtbUjJ0p/1mFzoT9FkCj37s9BjaB2oZO /GTzOFZs53BajAo5ewqusPu5Hg1od1AaqYZhUTrYCU7khtueDnF4YXbx5x4/KKRoimy3/a SjUKHzW1uGThPssBWSsbg7nf08H3rs0slANQux17VwARAFNRRCy4LYzMJP2aCQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021081301 header.b=fKq2ewOi; dmarc=pass (policy=none) header.from=fsfe.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -8.54 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021081301 header.b=fKq2ewOi; dmarc=pass (policy=none) header.from=fsfe.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 960083437B X-Spam-Score: -8.54 X-Migadu-Scanner: scn0.migadu.com X-TUID: TI2cCrE9e0UH Hi, zimoun writes: > Hi, > > This could be part of a RFC process. :-) > > > The Big Change introduces new style, other said, this old > > --8<---------------cut here---------------start------------->8--- > (native-inputs > `(("perl" ,perl) > ("pkg-config" ,pkg-config))) > --8<---------------cut here---------------end--------------->8--- > > is replaced by this new, > > --8<---------------cut here---------------start------------->8--- > (native-inputs > (list perl pkg-config)) > --8<---------------cut here---------------end--------------->8--- > > It removes all the labels. \o/ More details [1]. > > > We had a discussion on IRC starting here [2]. This proposal is to > document in the manual and adapt =E2=80=98guix style=E2=80=99 to have one= input per line > =E2=80=93 as it was the case with the old style. > > Aside preference, for instance, I find easier to read, > > --8<---------------cut here---------------start------------->8--- > (inputs ;required for test > (list julia-chainrulestestutils > julia-finitedifferences > julia-nanmath > julia-specialfunctions)) > (propagated-inputs > (list julia-chainrulescore > julia-compat > julia-reexport > julia-requires)) > --8<---------------cut here---------------end--------------->8--- > > than > > --8<---------------cut here---------------start------------->8--- > (inputs ;required for test > (list julia-chainrulestestutils julia-finitedifferences julia-nanmath > julia-specialfunctions)) > (propagated-inputs > (list julia-chainrulescore julia-compat julia-reexport > julia-requires)) > --8<---------------cut here---------------end--------------->8--- > > but this is somehow bikeshed. However, the current situation leads to > non-uniform or ambiguity. > > For example, the comments as here: > > --8<---------------cut here---------------start------------->8--- > (inputs > (list libx11 libiberty ;needed for objdump support > zlib)) ;also needed for objdump support > --8<---------------cut here---------------end--------------->8--- Yuck indeed! > when the comments apply to only one line as it was: > > --8<---------------cut here---------------start------------->8--- > `(("libx11" ,libx11) > ("libiberty" ,libiberty) ;needed for objdump support > ("zlib" ,zlib))) ;also needed for objdump su= pport > --8<---------------cut here---------------end--------------->8--- > > Other said, this looks better: > > --8<---------------cut here---------------start------------->8--- > (inputs > (list libx11 > libiberty ;needed for objdump support > zlib)) ;also needed for objdump support > --8<---------------cut here---------------end--------------->8--- > > Obviously, we could come up a rule depending on comments, numbers of > inputs, length, etc. It was not the case with the old style when > nothing prevented us to do it. Because one item per line is, IMHO, > easier to maintain. You seem to be putting the cart before the horse here; we should not let our (lack of) tooling determine our styling preferences. > Consider the case, > > (inputs > (list bar foo1 foo2 foo3 foo3 foo4)) > > then another =E2=80=99baz=E2=80=99 inputs is added, do we end with, > > (inputs > (list bar foo1 foo2 foo3 foo3 foo4 > baz)) > > to minimize and ease reading the diff, or do we end with, > > (inputs > (list bar > baz > foo1 > foo2 > foo3 > foo3 > foo4)) The second, ideally. > ? And the converse is also true, consider the case just above and what > happens if foo1, foo2 and foo3 are removed. Everything gets put on a single line again. > One item per line solves all these boring cosmetic questions. To be fair, any policy that can be automatically applied solves those very same boring cosmetic questions. I agree that whatever style we end up with, we should be able to automatically apply it.=20 > Therefore, I propose to always have only one item per line. To be > concrete, for one item: > > (inputs > (list foo)) > > or not > > (inputs (list foo)) > > And for more than one item: > > (inputs > (list foo > bar)) > > This would avoid =E2=80=9Ccosmetic=E2=80=9D changes when adding/removing = inputs and/or > comments. This is not a convincing argument to me; I very much doubt that we have that many packages that switch back and forth between having <=3D 4 and > 4 inputs constantly. That is not to say that I think we won't see it happen; I just don't think it happens often enough to warrant what you are proposing :-). > Sadly, it implies another Big Change. But earlier is better and we > should do it as soon as possible while the conversion is not totally > done yet. I agree, so here's a counter-proposal: adjust the convention and guix style to leave inputs-with-comments alone. Only put inputs on one line when there are fewer than N items (configurable, but for now 5), as well as no comments on any of the lines. > Cheers, > simon > > 1: > 2: - Jelle