[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Convention for new “guix style“?
From: |
Jelle Licht |
Subject: |
Re: Convention for new “guix style“? |
Date: |
Wed, 22 Dec 2021 15:10:58 +0100 |
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