Re: Removing package input labels: last call!

["Ludovic Courtès" <ludo@gnu.org>]

Hi Gabriel,

Gabriel Wicki <gabriel@erlikon.ch> skribis:

>  - Since not all the inputs *have* to be converted to the new format:
>    is this more some kind of syntactic sugar and less of a "we really
>    want this to be the new standard" kind of improvement?
>    Or is the goal to replace *all* input lists with the new style?

The goal is to replace all input lists with the new style.  We know
it’ll take time, but hopefully automation will reduce that.

>  - Regarding the speed of the transition: do I understand correctly that
>    the script should be able to convert the vast majority of packages
>    and that afterwards maybe other definitions will/might/could be
>    translated by hand?

Yes.  ‘guix style’ can translate “simple” cases, and it has three
strategies now (via the ‘--input-simplification’ option) with varying
degrees of impact.

More complex cases will have to be translated by hand over time.

>  - Follow up: is your intention to adjust the script to work with more
>    and more package definitions or are you leaning into a more "let's
>    have a sound script which is useful for many cases but leaves a
>    biggish bunch of manual labor but at least it won't break a thing"
>    kind of solution?

We can always improve the script if we find that it doesn’t handle
idioms that are quite widespread.  We can reduce the amount of manual
labor but it won’t be zero.

>  - Is there a way to check the integrity of a package definition
>    *without* building the whole thing?  I had some ideas (see below)
>    for adding special cases to your `guix style` script but was unable
>    to test whether they actually work (because compiling tonnes of
>    codes unsurprisingly takes quite some time).

Yes, you can run ‘guix build -d PACKAGE’ before and after running ‘guix
style’ and confirm the derivation is the same (this is for
‘--input-simplification=silent’).

> What I found:
>  - Small things like libX11 vs libx11.  If I understood correctly the
>    new patch series takes care of this case.

Yes, with ‘--input-simplification={safe,always}’.

>  - I think there's a whole class of cases where version-names and
>    other package-definition specifics make the "does-the-package-name-
>    match-the-label-exactly" algo fail:
>     - ,python-wrapper vs. "python"
>     - ,python-minimal-wrapper vs. "python"
>     - ,python2 vs. "python"
>     - ,python-cython vs. "cython"
>     - ,iproute2 vs. "iproute"
>     - etc

True!  ‘guix lint -c input-labels’ reports tons of them, but ‘guix
style --input-simplification=safe’ should also handle most of them
(though I didn’t measure that).

At worst we can always add special cases to the ‘label-matches?’
predicate.

Thanks for your feedback!  It’s very useful to have feedback from
another person who’s looked into it and who might find issues that have
been overlooked.

Ludo’.