| Message ID | 20220214163838.1174-1-ludo@gnu.org |
|---|---|
| Headers | show |
| Series | Not showing upgraded/added packages in 'guix pull' | expand |
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’.