[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Convention for new “guix style“?
From: |
zimoun |
Subject: |
Re: Convention for new “guix style“? |
Date: |
Wed, 22 Dec 2021 22:56:28 +0100 |
Hi,
On Wed, 22 Dec 2021 at 22:18, Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:
> Am Mittwoch, dem 22.12.2021 um 14:05 +0100 schrieb zimoun:
> > --8<---------------cut here---------------start------------->8---
> > `(("libx11" ,libx11)
> > ("libiberty" ,libiberty) ;needed for objdump
> > ("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---
[...]
> For me personally, this illustrates two things. First, the weakness of
> line comments over preceding line comments ad second the verbosity of
> old input style. You could easily write
>
> (list libiberty zlib) ; for objdump
What about 'libx11'? Otherwise, you end with cons (append for some
cases) or something along these lines,
(inputs
(cons
libx11
(list libiberty zlib))) ;for objdump
I am not convinced it is better...
> in the new style, which you couldn't before. Therefore, I wouldn't
Yes, I could do it in the old style:
`(("libx11" ,libx11)
("libiberty" ,libiberty) ("zlib" ,zlib))) ;for objdump support
I have never read such thing. And I miss your point because from my
understanding, it is not related to old style (list using labels)
versus new style (just list).
> mandate a "one line per input" restriction, as the only reason it was
> ever imposed was a historical limitation.
I miss your comment here. It is possible to write
(inputs `(("foo" ,bar) ("baz" ,done)))
and I have not done stats but I guess the rule for old style is: one
item per line whatever the numbers, comments or length. Because, I
guess again, readibility matters. :-)
> > This would avoid “cosmetic” changes when adding/removing inputs
> > and/or comments.
>
> In my personal opinion, everything else being equal, changes to
> inputs/native-inputs/propagated-inputs should (almost) always be seen
> as changes to the field, as would be documented in the ChangeLog.
>
> I think the usual scheme coding guidelines also apply well to inputs,
> e.g. inline short stuff, but don't do funky things when the lines grow
> unnecessarily long.
If that argument holds, then why is it not applied for old style? ;-)
We do not read,
--8<---------------cut here---------------start------------->8---
(native-inputs
`(("pkg-config" ,pkg-config) ("python" ,python-wrapper)))
--8<---------------cut here---------------end--------------->8---
for gnu/packages/video.scm (mediasdk) as example.
Cheers,
simon