[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Convention for new “guix style“?
From: |
zimoun |
Subject: |
Convention for new “guix style“? |
Date: |
Wed, 22 Dec 2021 14:05:06 +0100 |
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 ‘guix style’ to have one input per line
– 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---
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 support
--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.
Consider the case,
(inputs
(list bar foo1 foo2 foo3 foo3 foo4))
then another ’baz’ 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))
? And the converse is also true, consider the case just above and what
happens if foo1, foo2 and foo3 are removed.
One item per line solves all these boring cosmetic questions.
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 “cosmetic” changes when adding/removing inputs and/or
comments.
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.
Cheers,
simon
1: <https://guix.gnu.org/en/blog/2021/the-big-change/>
2: <https://logs.guix.gnu.org/guix/2021-12-20.log#121156>
- Convention for new “guix style“?,
zimoun <=