Convention for new “guix style“?

[zimoun <zimon.toutoune@gmail.com>]

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>