hi guixers, is there a command to build all dependents of a package? for example, i'd like to build all the dependents of python-identify that are packaged in GNU Guix: $ guix refresh python-identify -l Building the following 14 packages would ensure 28 dependent packages are rebuilt: python-multivelo@0.1.2 repo2docker@2021.08.0 python-matplotlib-documentation@3.5.2 python-numpy-documentation@1.21.6 jami-docs@0.0.0-0.b00574b mdpo@0.3.6 python-flask-combo-jsonapi@1.1.0 onionshare@2.5 python-jupytext@1.14.1 python-minikanren@1.0.1 python-miio@0.5.11 python-interrogate@1.5.0 pre-commit@2.20.0 babi@1.5.3 I'd also like to filter out packages from guixrus. babi@1.5.3 is in guixrus. wdyt
Hi, On Mon, 21 Nov 2022 at 19:06, jgart <jgart@dismail.de> wrote: > is there a command to build all dependents of a package? [...] > $ guix refresh python-identify -l > Building the following 14 packages would ensure 28 dependent packages > are rebuilt: python-multivelo@0.1.2 repo2docker@2021.08.0 > python-matplotlib-documentation@3.5.2 > python-numpy-documentation@1.21.6 jami-docs@0.0.0-0.b00574b mdpo@0.3.6 > python-flask-combo-jsonapi@1.1.0 onionshare@2.5 python-jupytext@1.14.1 > python-minikanren@1.0.1 python-miio@0.5.11 python-interrogate@1.5.0 > pre-commit@2.20.0 babi@1.5.3 $ guix build $(guix refresh python-identify -l | cut -f2 -d':') > I'd also like to filter out packages from guixrus. babi@1.5.3 is in guixrus. From the command-line, it can be tedious to filter. I would go with a manifest. Although, I am always confused by unexported bindings. This, (define list-dependents (@@ (guix scripts refresh) list-dependents)) returns, --8<---------------cut here---------------start------------->8--- /tmp/manifest.scm:6:3: error: list-dependents: unbound variable hint: Did you forget a `use-modules' form? --8<---------------cut here---------------end--------------->8--- but that’s the way I would do: list dependent packages, then apply some filter based on module name (location). Cheers, simon
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --] On 2022-11-22, zimoun wrote: > On Mon, 21 Nov 2022 at 19:06, jgart <jgart@dismail.de> wrote: > >> is there a command to build all dependents of a package? > > [...] > >> $ guix refresh python-identify -l >> Building the following 14 packages would ensure 28 dependent packages >> are rebuilt: python-multivelo@0.1.2 repo2docker@2021.08.0 >> python-matplotlib-documentation@3.5.2 >> python-numpy-documentation@1.21.6 jami-docs@0.0.0-0.b00574b mdpo@0.3.6 >> python-flask-combo-jsonapi@1.1.0 onionshare@2.5 python-jupytext@1.14.1 >> python-minikanren@1.0.1 python-miio@0.5.11 python-interrogate@1.5.0 >> pre-commit@2.20.0 babi@1.5.3 > > $ guix build $(guix refresh python-identify -l | cut -f2 -d':') This sometimes requires some manual fiddling, in my experience, e.g.: $ guix refresh --list-dependent guile-ssh Building the following 9 packages would ensure 10 dependent packages are rebuilt: cuirass@1.0.0-11.922cc66 emacs-guix@0.5.2-3.a694fdb guile-imanifest@0.0.0-0.ccd5a21 gwl@0.3.0 guix-jupyter@0.2.1 guix-build-coordinator@0-24.6fb5eaf guix-data-service@0.0.1-27.df2a0a7 hpcguix-web@0.0.1-5.9de6356 guix-daemon@1.3.0rc2-1.566982b $ guix build guix-daemon@1.3.0rc2-1.566982b guix build: error: guix-daemon: package not found for version 1.3.0rc2-1.566982b As the "guix-daemon" package is sometimes called "guix" instead. Not sure how many other cases like this there are. Given that it may in some cases require manually fiddling of package names, "guix refresh --build-dependent PACKAGE" would be nice. I vaguely recall discussing on irc not long ago the desire for "guix refresh --list-dependent --machine-readable" (e.g. drop the "Building the following X packages would ensure 10 dependent packages are rebuilt:") or something similar. Would save having to pipe to cut, awk, sed, perl, etc. ... I could also see, at least for completeness, "guix refresh --list-all-dependent" e.g. not hide the recursive dependencies, but show the whole list of packages to be rebuilt... I thought there was a bug about these sorts of things, but I haven't found it... live well, vagrant [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --] > This sometimes requires some manual fiddling Thanks for highlighting that. I've never encountered it. This is similar to another recent bug report, where ‘guix show’ listed something as depending on a hidden package. Or something like that. How is this not a bug? A package manager CLI that so routinely lists bogus ‘packages’ that break the very same CLI is silly. We're so used to it happening in Guix that we don't notice, or tolerate it when we do, or pile on ad hoc work-arounds because we broke the obvious sed to begin with. Two possible solutions: - Hide hidden packages. This makes the most sense to me. You'd still report accurate[0] numbers for ‘guix refresh -l’. - Allow referring to hidden packages in some contexts, or maybe all contexts, and keep listing them in ‘advanced’ tools like ‘guix refresh -l’. There are probably more. Kind regards, T G-R [0]: Of course these numbers aren't accurate anyway, because inheritance. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 247 bytes --]
Hi,
On Mon, Nov 21, 2022 at 5:07 PM jgart <jgart@dismail.de> wrote:
>
> is there a command to build all dependents
I struggle regularly with the terminology used in software
distributions. Perhaps someone appreciates my favorite act of civil
disobedience: I use "prerequisites" to talk about packages required by
those that "consume" them.
Here, I would have used "consuming packages" instead of dependents,
because the former is so clearly distinct from the ubiquitous but
ambiguous word "dependencies".
Happy hacking, and thank you all for your contributions to Guix!
Kind regards
Felix
On Tue, 22 Nov 2022 12:06:43 -0800 Felix Lechner <felix.lechner@lease-up.com> wrote: > Here, I would have used "consuming packages" instead of dependents, > because the former is so clearly distinct from the ubiquitous but > ambiguous word "dependencies". How about "dag kiddies"? > Happy hacking, and thank you all for your contributions to Guix! Thank you too!
On Tue, 22 Nov 2022 14:29:43 -0600 jgart <jgart@dismail.de> wrote:
> On Tue, 22 Nov 2022 12:06:43 -0800 Felix Lechner <felix.lechner@lease-up.com> wrote:
> How about "dag kiddies"?
or dag kittens?
Hi, On Tue, 22 Nov 2022 at 20:55, Tobias Geerinckx-Rice <me@tobias.gr> wrote: >> This sometimes requires some manual fiddling > > Thanks for highlighting that. I've never encountered it. > > This is similar to another recent bug report, where ‘guix show’ > listed something as depending on a hidden package. Or something > like that. If you are referring to bug#59278, the bug is on the package definition side. As explained here [1], the ’hidden’ properties is dropped out at one ’inherit’. 1: http://issues.guix.gnu.org/msgid/87h6yz46wp.fsf@gmail.com > Two possible solutions: > > - Hide hidden packages. This makes the most sense to me. You'd > still report accurate[0] numbers for ‘guix refresh -l’. > > - Allow referring to hidden packages in some contexts, or maybe > all contexts, and keep listing them in ‘advanced’ tools like > ‘guix refresh -l’. I agree that what is hidden is not clear. Maybe a marker could be added when displaying the hidden packages in “guix refresh -l”. It would allow to filter them out. Or we could separate the regular packages to the hidden one, --8<---------------cut here---------------start------------->8--- $ guix refresh -l guile-ssh Building the following 19 packages would ensure 26 dependent packages are rebuilt: emacs-guix@0.5.2-6.cf5b7a4 guile-imanifest@0.0.0-0.ccd5a21 cl-ospm@0.0.1 gwl@0.5.0 guix-jupyter@0.2.2 guix-build-coordinator@0-65.26fe4a7 guix-build-coordinator-agent-only@0-65.26fe4a7 gwl-next@0.5.0-1.706a089 nar-herder@0-9.5acfcc0 guix-modules@0.1.0 hpcguix-web@0.2.0 guix-data-service@0.0.1-33.ee73d2c numix-gtk-theme@2.6.7 arc-theme@20220405 gnome-shell-extension-gsconnect@50 gnome-terminal@3.44.1 gnome@42.4 cuirass@1.1.0-11.9f08035 '(@@ (gnu packages package-management) guix-daemon)' --8<---------------cut here---------------end--------------->8--- Well, maybe a rework of the submission #58824 [1]. 1: <http://issues.guix.gnu.org/msgid/20221027212706.21680-1-paren@disroot.org> Cheers, simon