[bug#54000,0/2] Not showing upgraded/added packages in 'guix pull'

Hello!

As a followup to <https://issues.guix.gnu.org/53909>, these patches
remove the list of added/upgraded packages from the output of
‘guix pull’ (upon completion) and ‘guix pull --news’.

It’s not spring yet in this hemisphere, but it looks like a spring cleanup!

Ludo’.

Ludovic Courtès (2):
  pull: '--news' no longer shows package lists.
  pull: No longer print upgraded/added packages upon completion.

 doc/guix.texi         | 10 ++---
 guix/scripts/pull.scm | 98 +++++++++++++++++++++++--------------------
 2 files changed, 57 insertions(+), 51 deletions(-)


base-commit: 41000d16c5c1586482a76d856c3152a6b8fcce8a
  

Am Montag, dem 14.02.2022 um 17:38 +0100 schrieb Ludovic Courtès:
> Hello!
> 
> As a followup to <https://issues.guix.gnu.org/53909>, these patches
> remove the list of added/upgraded packages from the output of
> ‘guix pull’ (upon completion) and ‘guix pull --news’.
> 
> It’s not spring yet in this hemisphere, but it looks like a spring
> cleanup!
> 
> Ludo’.
> 
> Ludovic Courtès (2):
>   pull: '--news' no longer shows package lists.
>   pull: No longer print upgraded/added packages upon completion.
What if I wanted that information however?  Does `guix pull --news --
details` still give it to me?  I don't really want to do `guix pull -l
1d --details` instead.

Cheers
  

Hi,

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis:

> Am Montag, dem 14.02.2022 um 17:38 +0100 schrieb Ludovic Courtès:
>> Hello!
>> 
>> As a followup to <https://issues.guix.gnu.org/53909>, these patches
>> remove the list of added/upgraded packages from the output of
>> ‘guix pull’ (upon completion) and ‘guix pull --news’.

[...]

>>   pull: '--news' no longer shows package lists.
>>   pull: No longer print upgraded/added packages upon completion.
> What if I wanted that information however?

Is it an actual use case or speculation?

> Does `guix pull --news -- details` still give it to me?

Not with this patch, but we could do that *if* there’s a need.

> I don't really want to do `guix pull -l 1d --details` instead.

OK.  So far, my impression was that this information was hardly used at
all, which is why it seemed reasonable to keep it behind ‘--details
--list-generations’.

I’m open to supporting ‘--news --details’, but only if it corresponds to
a real use case.

Thanks,
Ludo’.
  

Hi Ludo,

Am Donnerstag, dem 17.02.2022 um 11:19 +0100 schrieb Ludovic Courtès:
> Hi,
> 
> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis:
> 
> > Am Montag, dem 14.02.2022 um 17:38 +0100 schrieb Ludovic Courtès:
> > > Hello!
> > > 
> > > As a followup to <https://issues.guix.gnu.org/53909>, these
> > > patches
> > > remove the list of added/upgraded packages from the output of
> > > ‘guix pull’ (upon completion) and ‘guix pull --news’.
> 
> [...]
> 
> > >   pull: '--news' no longer shows package lists.
> > >   pull: No longer print upgraded/added packages upon completion.
> > What if I wanted that information however?
> 
> Is it an actual use case or speculation?
That's a use case.  While --dry-run exists, I don't really want it to
serve double duty here.  If I previously guix pulled and only three new
packages were added, none of which I'm interested in, I would not have
to meaninglessly run further build commands like guix package or guix
system.  Even if the list is potentially longer, I could visually grep
for a few packages I'm interested in and determine whether it'd make
sense to build now or wait for a little while as I'm processing other
things.

> > Does `guix pull --news -- details` still give it to me?
> 
> Not with this patch, but we could do that *if* there’s a need.
> 
> > I don't really want to do `guix pull -l 1d --details` instead.
> 
> OK.  So far, my impression was that this information was hardly used
> at all, which is why it seemed reasonable to keep it behind ‘--
> details --list-generations’.
> 
> I’m open to supporting ‘--news --details’, but only if it corresponds
> to a real use case.
In general, it doesn't have to be named ‘--news --details’, but a means
of diffing two generations via the CLI -- in particular the current one
to the last -- would be very welcome, because then all information we
previously had would still be available quite easily, albeit no longer
printed by default.

Cheers
  

Hi Liliana,

On Thu, 17 Feb 2022 at 11:30, Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> wrote:

>> Is it an actual use case or speculation?
>
> That's a use case.  While --dry-run exists, I don't really want it to
> serve double duty here.  If I previously guix pulled and only three new
> packages were added, none of which I'm interested in, I would not have
> to meaninglessly run further build commands like guix package or guix
> system.  Even if the list is potentially longer, I could visually grep
> for a few packages I'm interested in and determine whether it'd make
> sense to build now or wait for a little while as I'm processing other
> things.

Stats, ~24 updates and ~13 additions per day on average (over the past
year).  If you pull twice a day, then yes you can read this information.
But, I bet people pull once a week, at best, so it looks like more
“noise“ and I guess most people miss the news.

About grepping, it is not straightforward.  For instance, I get this: 

--8<---------------cut here---------------start------------->8---
$ guix pull --news | grep python 
    openshadinglanguage, perl-date-range, pgcli, plfit, poweralertd, pproxy, python-aiosignal, python-android-backup,
    python-asdf-astropy, python-astral, python-astropy-healpix, python-astroquery, python-canvasapi, python-cmarkgfm,
    python-cucumber-tag-expressions, python-cython-next, python-doit, python-esprima, python-executing,
    python-flask-assets, python-flit-core-bootstrap, python-frozenlist, python-fs, python-geojson, python-gwcs,
    python-ipython-sql, python-markdownify, python-miio, python-pgspecial, python-photutils, python-phpserialize,
    python-piexif, python-psycopg, python-psycopg-pool, python-pydbus, python-pyftpdlib, python-pylru, python-pyowm,
    python-pypdf3, python-pyrss2gen, python-pyscss, python-pysendfile, python-pystitcher,
    python-pytest-doctest-custom, python-pytest-metadata, python-pytest-pydocstyle, python-pyvo, python-reedsolo,
    python-regions, python-retry, python-roundrobin, python-sarge, python-sentry-sdk, python-setuptools-rust,
    python-sphinx-click, python-sphinxcontrib-apidoc, python-tomli-w, python-tweepy, python-typeguard,
--8<---------------cut here---------------end--------------->8---

So I do not think the current display is adequate for grepping.


Somehow, the feature you want should be separated.  For instance,

    guix pull --updated
    guix pull --added
    guix pull --new-versions


> In general, it doesn't have to be named ‘--news --details’, but a means
> of diffing two generations via the CLI -- in particular the current one
> to the last -- would be very welcome, because then all information we
> previously had would still be available quite easily, albeit no longer
> printed by default.

That feature is interesting but it appears to me orthogonal with the
current proposal.


Cheers,
simon
  

Hi zimoun,

Am Donnerstag, dem 17.02.2022 um 13:04 +0100 schrieb zimoun:
> Hi Liliana,
> 
> Stats, ~24 updates and ~13 additions per day on average (over the
> past year).  If you pull twice a day, then yes you can read this
> information.
> But, I bet people pull once a week, at best, so it looks like more
> “noise“ and I guess most people miss the news.
For the record, that's < 150 updates and < 100 additions per week.  Of
course, these numbers tend to get higher as Guix grows, but for now I
personally find this both manageable and helpful.  Which doesn't mean I
want it done by default, just that I want a way of doing it.

Furthermore, news are displayed at the bottom, so if you're not
interested in the noise, just don't scroll up :P
Granted, if you're piping the output to a pager, that doesn't help you.

> About grepping, it is not straightforward.  For instance, I get this:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix pull --news | grep python 
>     openshadinglanguage, perl-date-range, pgcli, plfit, poweralertd,
> pproxy, python-aiosignal, python-android-backup,
>     python-asdf-astropy, python-astral, python-astropy-healpix,
> python-astroquery, python-canvasapi, python-cmarkgfm,
>     python-cucumber-tag-expressions, python-cython-next, python-doit,
> python-esprima, python-executing,
>     python-flask-assets, python-flit-core-bootstrap, python-
> frozenlist, python-fs, python-geojson, python-gwcs,
>     python-ipython-sql, python-markdownify, python-miio, python-
> pgspecial, python-photutils, python-phpserialize,
>     python-piexif, python-psycopg, python-psycopg-pool, python-
> pydbus, python-pyftpdlib, python-pylru, python-pyowm,
>     python-pypdf3, python-pyrss2gen, python-pyscss, python-
> pysendfile, python-pystitcher,
>     python-pytest-doctest-custom, python-pytest-metadata, python-
> pytest-pydocstyle, python-pyvo, python-reedsolo,
>     python-regions, python-retry, python-roundrobin, python-sarge,
> python-sentry-sdk, python-setuptools-rust,
>     python-sphinx-click, python-sphinxcontrib-apidoc, python-tomli-w,
> python-tweepy, python-typeguard,
> --8<---------------cut here---------------end--------------->8---
> 
> So I do not think the current display is adequate for grepping.
I agree that with certain packages that's a little harder to do than
with others, but particularly with python the way to resolve this would
be to grep for 'python@'

> Somehow, the feature you want should be separated.  For instance,
> 
>     guix pull --updated
>     guix pull --added
>     guix pull --new-versions
That would perhaps help if your aim is to optimize for computation
time, but I'd still prefer all changes.  It also helps that we already
have that code, so we only have to tell people to e.g. use --changes
instead of --news if that is the thing they wanted.  
W.r.t. only listing some of the changes, one could later implement
options like --changes=added,removed,updated,rewritten,...


> > In general, it doesn't have to be named ‘--news --details’, but a
> > means of diffing two generations via the CLI -- in particular the
> > current one to the last -- would be very welcome, because then all
> > information we previously had would still be available quite
> > easily, albeit no longer printed by default.
> 
> That feature is interesting but it appears to me orthogonal with the
> current proposal.
Orthogonal in which way?  In that we could implement such a feature
without changing the way `guix pull' normally works and vice versa? 
Sure.  In that we'd not be losing any information if we changed `guix
pull' without providing such an option?  Eh...
  

Hi Liliana,

On Thu, 17 Feb 2022 at 13:52, Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> wrote:

>> Stats, ~24 updates and ~13 additions per day on average (over the
>> past year).  If you pull twice a day, then yes you can read this
>> information.
>> But, I bet people pull once a week, at best, so it looks like more
>> “noise“ and I guess most people miss the news.
>
> For the record, that's < 150 updates and < 100 additions per week.  Of
> course, these numbers tend to get higher as Guix grows, but for now I
> personally find this both manageable and helpful.  Which doesn't mean I
> want it done by default, just that I want a way of doing it.

On my poor laptop, I barely pull.  Last time, more than 2 weeks ago.

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 76	Feb 04 2022 11:15:54	(current)
  guix ff093f5
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: ff093f5739a61e77b296feccc48d260b9bb574c0
--8<---------------cut here---------------end--------------->8---

and a typical ‘guix pull --news’ looks like:

--8<---------------cut here---------------start------------->8---
$ time guix pull --news
New in this revision:
  416 new packages: alfis,

[...]

  877 packages upgraded: amsynth@1.12.4,

[...]


News for channel 'guix'
  New `--execute' option to `guix deploy'
    commit 5c13484646069064c834bbd3cd02c3bc80d94cb6

    The `guix deploy' command has a new `--execute' or
    `-x' option, which allows you to execute a command on
    all the machines that your configuration file
    specifies, as in this example:
    
         guix deploy deploy.scm -x -- herd restart guix-daemon
    
    This is no substitute for full-featured tools such as
    pdsh but it is a useful helper.
  `guix style' can format package definitions
    commit c4fe13c294cc1e31dd8a49ce3981f603fb169e0a

    The recently-introduced `guix style' command can now
    be used to automatically format package definitions
    according to the Guix project's formatting guidelines.
    If you contribute packages to Guix or to a third-party
    channel, you may find it useful.
    
    The new `--styling' option can currently be passed one
    of the following "styling rules": `format', to format
    package definitions, or `inputs', to remove labels
    from package inputs.  Omitting `--styling' is
    equivalent to passing `--styling=format'; previously
    it was equivalent to `--styling=inputs'.
    
    Run `info "(guix) Invoking guix style"', for more
    info.


real	0m7.796s
user	0m8.131s
sys	0m0.500s
--8<---------------cut here---------------end--------------->8---


> Furthermore, news are displayed at the bottom, so if you're not
> interested in the noise, just don't scroll up :P
> Granted, if you're piping the output to a pager, that doesn't help you.

First, because it is too much information, I never do it.
Second, because it is really slow, I never do it.
Therefore, I never read the news.

Well, I read them from Git, browsing after fetching. :-)  Not sure it is
adequate.

I barely upgrade my base system – I made it work once and just use it –
and instead I heavily rely on time-machine and shell.

I agree with your request and I understand the need.  Even, I think
diffing generations can be useful.  But we should keep the default as
simple and fast as possible.


>> Somehow, the feature you want should be separated.  For instance,
>> 
>>     guix pull --updated
>>     guix pull --added
>>     guix pull --new-versions
>
> That would perhaps help if your aim is to optimize for computation
> time, but I'd still prefer all changes.  It also helps that we already
> have that code, so we only have to tell people to e.g. use --changes
> instead of --news if that is the thing they wanted.  
> W.r.t. only listing some of the changes, one could later implement
> options like --changes=added,removed,updated,rewritten,...

We agree.

My point was just to say that ‘--news --details’ is not the correct UI
for the feature you would like because, for instance, currently
’--details’ alone is equivalent to ’--details -l’.  Therefore, what
happens if the user only provides ’--details’?

The option ’--changes=’ makes also sense and it is probably a good
direction; instead of ’--news --details’.

Well, my point is just to say that the feature you want should be
separated from ‘--news’. :-)


>> That feature is interesting but it appears to me orthogonal with the
>> current proposal.
>
> Orthogonal in which way?  In that we could implement such a feature
> without changing the way `guix pull' normally works and vice versa? 
> Sure.  In that we'd not be losing any information if we changed `guix
> pull' without providing such an option?  Eh...

Well, from my point of view, ‘guix pull -l 1d --details’ fits the job
and I miss why it would be an issue; since such display would be barely
used.

To be precise, the option ’-l’ should accept ’last’.  From my point of
view, it is better to have:

    guix pull --news            # just the last news
    guix pull -l last --details

(better meaming encourage people to read news :-)


And we could also imagine some options as ’--details=added’.  Note we
could also imagine to make ‘guix git log’ show some information.  Lot of
imagination. ;-)

Cheers,
simon
  

Hey comrades, hold your horses!  :-)

Since there’s a need for this, we can make ‘--details’ print package
lists when combined with ‘--news’; it doesn’t cost us anything, that’s
OK.

There may be a need for more general package version diffing and such
things, but we can address it separately.

Thanks,
Ludo’.
  

Am Freitag, dem 18.02.2022 um 10:08 +0100 schrieb Ludovic Courtès:
> Hey comrades, hold your horses!  :-)
> 
> Since there’s a need for this, we can make ‘--details’ print package
> lists when combined with ‘--news’; it doesn’t cost us anything,
> that’s OK.
Regarding the issue simon raised w.r.t. --details implying -l, I think
--details should only imply listing the latest generation if -l is not
specified.  That way --news --details would (hopefully) work as I
intended, and specifying one without the other would only print that
part.

On a separate note, would/should guix describe be affected by this? 
Its output appear currently the same as `guix pull -l
$CURRENT_GENERATION', but I haven't tested this on a generation
including news.  My guess would be "no" as guix describe currently
doesn't accept --news.

Cheers
  

Hi,

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis:

> Am Freitag, dem 18.02.2022 um 10:08 +0100 schrieb Ludovic Courtès:
>> Hey comrades, hold your horses!  :-)
>> 
>> Since there’s a need for this, we can make ‘--details’ print package
>> lists when combined with ‘--news’; it doesn’t cost us anything,
>> that’s OK.
> Regarding the issue simon raised w.r.t. --details implying -l, I think
> --details should only imply listing the latest generation if -l is not
> specified.  That way --news --details would (hopefully) work as I
> intended, and specifying one without the other would only print that
> part.

Right, I went with something like you describe:

  2ddfb7b99b pull: No longer print upgraded/added packages upon completion.
  bc8bea1739 pull: '--news' no longer shows package lists.

That is, one can run ‘guix pull -N --details’ and get what you asked
for.  Running ‘guix pull --details’ alone still implies ‘-l’.

Let me know if anything’s amiss.

> On a separate note, would/should guix describe be affected by this? 
> Its output appear currently the same as `guix pull -l
> $CURRENT_GENERATION', but I haven't tested this on a generation
> including news.  My guess would be "no" as guix describe currently
> doesn't accept --news.

No, ‘guix describe’ doesn’t display news, profile changes, and all
that.  It’s meant to just show the raw channel info.

Thanks to both of you for your feedback!

Ludo’.