Re: Convention for new “guix style“?

[zimoun]

Hi Jelle,

We are consistent with what we already said on IRC. ;-)


On Wed, 22 Dec 2021 at 15:10, Jelle Licht <jlicht@fsfe.org> wrote:

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

Therefore, the tool requires a first “exception” for this case.

        (inputs
         (list foo bar
               baz           ;for tests
               bang boum))

The tool already contains an “exception” for this other case.

--8<---------------cut here---------------start------------->8---
        (inputs
         (list julia-chainrulestestutils julia-finitedifferences julia-nanmath
               julia-specialfunctions))
--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.

Hum, I do not know.  Maybe.  For sure, I write my grocery list as:

 + apple
 + orange
 + beer
 + flour

and not,

 apple orange beer flour

but all the flavours are equal. :-)


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

This makes the diffs harder to deal with.  Because one part of the issue
is about comparing revision A with revision B, not just the read the
list at one specific revisin.  Going back and forth to multi and single
line is error-prone, IMHO.

I agree that 1. comparing does not happen so frequently but still, and
2. it does not happen to so many packages but still.

For sure, S-Diff presented by Arun [1] at last FOSDEM 2021 would help.
AFAIK, this kind of tool is not ready for day-to-day usage and not yet
integrated with Git.

1: <https://archive.fosdem.org/2021/schedule/event/sexpressiondiff/>


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

I agree that tools can help.  However, at some point, we effectively
read and the default policy should ease this reading, even with plain
text without any tools.

«Automatically apply it» is not straightforward.  We already have a
great tool “guix lint” and it is not automatically applied.

For sure, I also think that automatic tools is the direction to go, for
sure I want more automation.  And “guix style” is a step toward fixing
Danny’s words:

        FWIW, I do find it strange that Lisp projects, despite using a
        minimal-syntax language (mostly in order to conserve its regular
        tree structure), do not usually automatically format source code
        as they check in, but Go projects, using the prime example of an
        irregular C-like language, DOES usually use code formatters
        automatically when checking in.  That is some strange reversal
        of strengths that I wouldn't have expected.

        <https://yhetil.org/guix/20201204161257.64363a5a@scratchpost.org/>


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

As I am pointing, comment is an issue, obscure diff is another, 4
long-names which splits into 2 lines is another.  These 3 cases are just
things that annoyed me reviewing OCaml update and packaging Julia, after
one week or so using this new style.

(Issue is a strong word for this bikeshed. ;-))


As a good coding style says: «Don't put multiple inputs on a single line
unless you have something to hide». ;-)

However, I do not see the advantages for one line. :-)


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

You are proposing to implement more “rules“. :-) Why not, but it appears
to me a French mindset ;-) add more cases and layers instead of just
simplify with one unique as simple as possible rule.


Cheers,
simon