Message ID | 20220214163838.1174-1-ludo@gnu.org |
---|---|
Headers |
Return-Path: <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org> X-Original-To: patchwork@mira.cbaines.net Delivered-To: patchwork@mira.cbaines.net Received: by mira.cbaines.net (Postfix, from userid 113) id 9813127BBEA; Mon, 14 Feb 2022 16:40:31 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mira.cbaines.net X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mira.cbaines.net (Postfix) with ESMTPS id 4ADEC27BBE9 for <patchwork@mira.cbaines.net>; Mon, 14 Feb 2022 16:40:31 +0000 (GMT) Received: from localhost ([::1]:56722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org>) id 1nJeOs-0001Of-Ay for patchwork@mira.cbaines.net; Mon, 14 Feb 2022 11:40:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1nJeOU-0001Ni-U5 for guix-patches@gnu.org; Mon, 14 Feb 2022 11:40:06 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48494) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1nJeOR-0001Ie-06 for guix-patches@gnu.org; Mon, 14 Feb 2022 11:40:06 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1nJeOQ-0005oM-N6 for guix-patches@gnu.org; Mon, 14 Feb 2022 11:40:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#54000] [PATCH 0/2] Not showing upgraded/added packages in 'guix pull' Resent-From: Ludovic =?utf-8?q?Court=C3=A8s?= <ludo@gnu.org> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org> Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 14 Feb 2022 16:40:02 +0000 Resent-Message-ID: <handler.54000.B.164485675022243@debbugs.gnu.org> Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 54000 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 54000@debbugs.gnu.org Cc: Ludovic =?utf-8?q?Court=C3=A8s?= <ludo@gnu.org> X-Debbugs-Original-To: guix-patches@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.164485675022243 (code B ref -1); Mon, 14 Feb 2022 16:40:02 +0000 Received: (at submit) by debbugs.gnu.org; 14 Feb 2022 16:39:10 +0000 Received: from localhost ([127.0.0.1]:42391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>) id 1nJeNZ-0005mg-PN for submit@debbugs.gnu.org; Mon, 14 Feb 2022 11:39:09 -0500 Received: from lists.gnu.org ([209.51.188.17]:35476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ludo@gnu.org>) id 1nJeNY-0005mZ-CY for submit@debbugs.gnu.org; Mon, 14 Feb 2022 11:39:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <ludo@gnu.org>) id 1nJeNX-00019I-3M for guix-patches@gnu.org; Mon, 14 Feb 2022 11:39:08 -0500 Received: from [2001:470:142:3::e] (port=35162 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <ludo@gnu.org>) id 1nJeNG-00015Z-Mm; Mon, 14 Feb 2022 11:39:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:Subject:To:From:in-reply-to: references; bh=w1/KCYavO97RCSuSAdt97IO8jmOAuLvu4IfMIlG5xRE=; b=rp8AcBCk8Y6v04 INUwPr9F77qzfsYpkUIgSY8rs6ZCoY1Q0qQ0sv7SQsapHFjGxoz8sTWMOJp6O/LMR032GPvkS/jXJ cSJeh5Ftv5gSTPnBtMmCj/TtBES+PgNPVMUWGyGBEogFVvg3M0LPwGFfMsI/K32r2GVHAxJY+ei8y zbRGnuQCRzJ58DT+8NTDe+iGWxyI7SsPVWyYiYp+zL/ocA/zogejceVXrgSPwn95IkXSRQZTBhJBD z0vM9kAVwjy0g5Ato/u/S8pDTJaS4ZZM0uHL9NslHZL4MNDqm3Q8H4zwfeF3HtZC61zuSK367inYp WEkiJIPr0FCumrKNbbfA==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:56750 helo=gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <ludo@gnu.org>) id 1nJeND-0003B4-Iw; Mon, 14 Feb 2022 11:38:50 -0500 From: Ludovic =?utf-8?q?Court=C3=A8s?= <ludo@gnu.org> Date: Mon, 14 Feb 2022 17:38:38 +0100 Message-Id: <20220214163838.1174-1-ludo@gnu.org> X-Mailer: git-send-email 2.34.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: <guix-patches.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-patches>, <mailto:guix-patches-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/guix-patches> List-Post: <mailto:guix-patches@gnu.org> List-Help: <mailto:guix-patches-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-patches>, <mailto:guix-patches-request@gnu.org?subject=subscribe> Errors-To: guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org Sender: "Guix-patches" <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org> X-getmail-retrieved-from-mailbox: Patches |
Series |
Not showing upgraded/added packages in 'guix pull'
|
|
Message
Ludovic Courtès
Feb. 14, 2022, 4:38 p.m. UTC
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
Comments
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’.