Re: Convention for new “guix style“?

[Jelle Licht]

Hi,

zimoun <zimon.toutoune@gmail.com> 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 ‘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---
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 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.

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 ’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))

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. 

> 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.

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 <= 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: <https://guix.gnu.org/en/blog/2021/the-big-change/>
> 2: <https://logs.guix.gnu.org/guix/2021-12-20.log#121156>

- Jelle