Removing package input labels: last call!

Removing package input labels: last call!

[Ludovic Courtès]

Hello Guix!

Just a heads-up: I plan to go ahead with the proposal to remove package
input labels on ‘core-updates’ in the coming days if there are no
objections:

  https://issues.guix.gnu.org/49169

I’m still interested in hearing about special cases that do not have an
obvious “translation”, and about any other concerns you may have.

Thanks.  :-)

Ludo’.

Re: Removing package input labels: last call!

[Gabriel Wicki]

Hi!

I hope I'm not too late!  I've given the patch a try and have a couple
of questions:

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

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

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


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

 - 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

I've written some code and tested it with some specific package
definitions but since I was unable to test whether these substitutions
actually work for *all* package definitions I'll just leave these
remarks here :)


I hope this is somewhat help- or useful.

Gabriel

Re: Removing package input labels: last call!

[Ludovic Courtès]

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