* bug#73599: packages from store paths don't propagate propagated-inputs @ 2024-10-02 14:46 MSavoritias 2024-10-02 18:22 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 0 siblings, 1 reply; 6+ messages in thread From: MSavoritias @ 2024-10-02 14:46 UTC (permalink / raw) To: 73599 With a package definition adding a propagated input. Using guix build to build a package like so: guix build --rounds=3 --no-substitutes --no-grafts --keep-failed --load-path=. <the package> and then taking the store path at the end for example: phase `compress-documentation' succeeded after 0.0 seconds successfully built /gnu/store/vcj7bq0igj2354m5pqk9zf1x0cnwgjzd-po4a-0.73.drv /gnu/store/j37fygmv7p69nmw0md916acinc8c8m4y-po4a-0.73 and installing it in the profile with guix package --install /gnu/store/j37fygmv7p69nmw0md916acinc8c8m4y-po4a-0.73 will not install the propagated input into the profile. It will only have po4a installed. $ guix package --install /gnu/store/j37fygmv7p69nmw0md916acinc8c8m4y-po4a-0.73 The following package will be installed: po4a 0.73 The following derivation will be built: /gnu/store/mc57jjaqlrmp0dw8sy2vlcv3c5giblk9-profile.drv building CA certificate bundle... listing Emacs sub-directories... building fonts directory... building directory of Info manuals... building profile with 1 package... $ guix package --list-installed po4a 0.73 out /gnu/store/j37fygmv7p69nmw0md916acinc8c8m4y-po4a-0.73 $ ;; This file was automatically generated and is for internal use only. ;; It cannot be passed to the '--manifest' option. ;; Run 'guix package --export-manifest' if you want to export a file ;; suitable for '--manifest'. (manifest (version 4) (packages (("po4a" "0.73" "out" "/gnu/store/j37fygmv7p69nmw0md916acinc8c8m4y-po4a-0.73")))) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#73599: packages from store paths don't propagate propagated-inputs 2024-10-02 14:46 bug#73599: packages from store paths don't propagate propagated-inputs MSavoritias @ 2024-10-02 18:22 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2024-10-03 7:39 ` MSavoritias 0 siblings, 1 reply; 6+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2024-10-02 18:22 UTC (permalink / raw) To: 73599, email; +Cc: ludo Hi [explicitly CC'ing Ludo', I hope that's OK], I don't think guix install $(guix build foo) is, or is expected to be, a supported way to install packages? Packages have more metadata attached to them than store items. I don't think that propagation is recorded in the Nix database. Nor do I think it should be just to support this hack. The manual doesn't explicitly say that it's semi-supported, which could be improved, but I think it's quietly understood... It happens to work most of the time, it can be nice to have (I install most firefox versions this way), we won't deliberately break the way it happens to work, but it's not a synonym of guix install foo Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#73599: packages from store paths don't propagate propagated-inputs 2024-10-02 18:22 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2024-10-03 7:39 ` MSavoritias 2024-10-03 8:07 ` MSavoritias 2024-10-03 9:29 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 0 siblings, 2 replies; 6+ messages in thread From: MSavoritias @ 2024-10-03 7:39 UTC (permalink / raw) To: me, 73599, email; +Cc: ludo [-- Attachment #1: Type: text/plain, Size: 1476 bytes --] Tobias Geerinckx-Rice kirjoitti 2.10.2024 klo 21.22: > Hi [explicitly CC'ing Ludo', I hope that's OK], > > I don't think > > guix install $(guix build foo) > > is, or is expected to be, a supported way to install packages? Packages have more metadata attached to them than store items. I don't think that propagation is recorded in the Nix database. Nor do I think it should be just to support this hack. It actually is mentioned explicitly in the manual. https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html from the link above: Alternatively, a package can directly specify a store file name such as /gnu/store/...-guile-3.0.7, as produced by, e.g., |guix build|. Sometimes packages have /propagated inputs/: these are dependencies that automatically get installed along with the required package (see |propagated-inputs| in |package| objects <https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#package_002dpropagated_002dinputs>, for information about propagated inputs in package definitions). There was an investigation yesterday at the xmpp room and that is how we discovered that the documentation has a bug. If we do not want to support it then this is just a documentation bug. Personally i could go either way. I already updated the project documentation I have to reflect not to do this https://codeberg.org/Guix_Bechamel/collective/wiki/Updating-Packages#testing-the-package-at-runtime MSavoritias [-- Attachment #2: Type: text/html, Size: 2597 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#73599: packages from store paths don't propagate propagated-inputs 2024-10-03 7:39 ` MSavoritias @ 2024-10-03 8:07 ` MSavoritias 2024-10-03 9:29 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 1 sibling, 0 replies; 6+ messages in thread From: MSavoritias @ 2024-10-03 8:07 UTC (permalink / raw) To: me, 73599; +Cc: ludo [-- Attachment #1: Type: text/plain, Size: 3142 bytes --] MSavoritias kirjoitti 3.10.2024 klo 10.39: > > > Tobias Geerinckx-Rice kirjoitti 2.10.2024 klo 21.22: >> Hi [explicitly CC'ing Ludo', I hope that's OK], >> >> I don't think >> >> guix install $(guix build foo) >> >> is, or is expected to be, a supported way to install packages? Packages have more metadata attached to them than store items. I don't think that propagation is recorded in the Nix database. Nor do I think it should be just to support this hack. > > It actually is mentioned explicitly in the manual. > https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html > > from the link above: > > Alternatively, a package can directly specify a store file name such > as /gnu/store/...-guile-3.0.7, as produced by, e.g., |guix build|. > > Sometimes packages have /propagated inputs/: these are dependencies > that automatically get installed along with the required package (see > |propagated-inputs| in |package| objects > <https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#package_002dpropagated_002dinputs>, > for information about propagated inputs in package definitions). > > > There was an investigation yesterday at the xmpp room and that is how > we discovered that the documentation has a bug. If we do not want to > support it then this is just a documentation bug. > > Personally i could go either way. I already updated the project > documentation I have to reflect not to do this > https://codeberg.org/Guix_Bechamel/collective/wiki/Updating-Packages#testing-the-package-at-runtime > > MSavoritias > Sorry for the second reply just wanted to add some additional things here. > Packages have more metadata attached to them than store items. I was very surprised to discover this yesterday when somebody pointed it out. The manual does not mention this in the store section. Is this because what you want is a nar that is retrieved only when doing guix export/import? at least that is my guess doing a search for metadata in the guix manual. Aside from that as a separate issue of concern it was mentioned that the Gnu Guix channel has solved this by doing the whole pre-inst-env architecture thing but i found little documentation to go on in the manual aside from "keeping things separate". There is also no mention of why it is needed, why these tools where picked, how the architecture is arranged and interacts or what each tool actually does. I tried to read the source files but there is not enough comments to go on. I assume it is expected to know pathing, unix, autotools, bash scripting among others but that is not mentioned and shouldn't be needed imo. Some clarifications of this would be nice but as I said these are out of scope of this bug report probably. Also some guide on the Guix manual by hopefully more knowledgeable people on how you are supposed to test packages at runtime would be nice. The guide only mentions to build packages but that doesn't make sure that packages actually work. namely: - po4a in the gnu channel of guix is atm broken. It misses gettext at runtime. - gajim doesn't show emojis MSavoritias [-- Attachment #2: Type: text/html, Size: 5287 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#73599: packages from store paths don't propagate propagated-inputs 2024-10-03 7:39 ` MSavoritias 2024-10-03 8:07 ` MSavoritias @ 2024-10-03 9:29 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2024-10-03 9:34 ` MSavoritias 1 sibling, 1 reply; 6+ messages in thread From: Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2024-10-03 9:29 UTC (permalink / raw) To: email, 73599; +Cc: ludo Heyo, On 3 October 2024 07:39:27 UTC, MSavoritias <email@msavoritias.me> wrote: >Tobias Geerinckx-Rice kirjoitti 2.10.2024 klo 21.22: >> is, or is expected to be, a supported way to install packages? Packages have more metadata attached to them than store items. I don't think that propagation is recorded in the Nix database. Nor do I think it should be just to support this hack. > >It actually is mentioned explicitly in the manual. https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html I think I was misunderstood. That is the part that needs improvement. It may not 'explicitly' say that propagation will work in both cases, but the flow strongly implies it. What I'm not aware of is any documentation that 'installing a store item' is not the same as 'installing a package'. It's a lossy transformation. See also: $ guix package -I sbcl-typo $ guix install sbcl-typo &>/dev/null $ guix package -I sbcl-typo sbcl-typo 0.0.0-0.0e88349 out /gnu/store/67nkzm5mw4ma39na24l9rv98gkfh3nbg-sbcl-typo-0.0.0-0.0e88349 $ guix package -r sbcl-typo -i $(guix build sbcl-typo) &>/dev/null $ guix package -I sbcl-typo sbcl-typo-0.0.0 0.0e88349 out /gnu/store/67nkzm5mw4ma39na24l9rv98gkfh3nbg-sbcl-typo-0.0.0-0.0e88349 $ guix package -r sbcl-typo guix package: error: package 'sbcl-typo' not found in profile Because <https://gitlab.oit.duke.edu/duke-guix/guix/-/blob/master/guix/scripts/package.scm?ref_type=heads#L619> — I guess Savannah's down again. Store items just aren't packages. >Personally i could go either way. I don't think you can, not *without* extending the database schema or otherwise adding the missing metadata back to the store item though, e.g., a hidden Scheme file, i.e., overkill. I'd love to be proven wrong. Otherwise, the documentation-bug way is the only realistic way. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#73599: packages from store paths don't propagate propagated-inputs 2024-10-03 9:29 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix @ 2024-10-03 9:34 ` MSavoritias 0 siblings, 0 replies; 6+ messages in thread From: MSavoritias @ 2024-10-03 9:34 UTC (permalink / raw) To: me, 73599; +Cc: ludo [-- Attachment #1: Type: text/plain, Size: 2283 bytes --] Tobias Geerinckx-Rice kirjoitti 3.10.2024 klo 12.29: > I think I was misunderstood. That is the part that needs improvement. It may not 'explicitly' say that propagation will work in both cases, but the flow strongly implies it. Agreed. >> Personally i could go either way. > I don't think you can, not *without* extending the database schema or otherwise adding the missing metadata back to the store item though, e.g., a hidden Scheme file, i.e., overkill. I'd love to be proven wrong. > > Otherwise, the documentation-bug way is the only realistic way. Documentation bug sounds good to me. It would also ideally be handled the same with the Documentation bugs i sent in the other email. I didn't see it reflected back to me so adding it here. Maybe email lists are having problems. > Packages have more metadata attached to them than store items. I was very surprised to discover this yesterday when somebody pointed it out. The manual does not mention this in the store section. Is this because what you want is a nar that is retrieved only when doing guix export/import? at least that is my guess doing a search for metadata in the guix manual. Aside from that as a separate issue of concern it was mentioned that the Gnu Guix channel has solved this by doing the whole pre-inst-env architecture thing but i found little documentation to go on in the manual aside from "keeping things separate". There is also no mention of why it is needed, why these tools where picked, how the architecture is arranged and interacts or what each tool actually does. I tried to read the source files but there is not enough comments to go on. I assume it is expected to know pathing, unix, autotools, bash scripting among others but that is not mentioned and shouldn't be needed imo. Some clarifications of this would be nice but as I said these are out of scope of this bug report probably. Also some guide on the Guix manual by hopefully more knowledgeable people on how you are supposed to test packages at runtime would be nice. The guide only mentions to build packages but that doesn't make sure that packages actually work. namely: - po4a in the gnu channel of guix is atm broken. It misses gettext at runtime. - gajim doesn't show emojis MSavoritias [-- Attachment #2: Type: text/html, Size: 3672 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-10-03 9:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-10-02 14:46 bug#73599: packages from store paths don't propagate propagated-inputs MSavoritias 2024-10-02 18:22 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2024-10-03 7:39 ` MSavoritias 2024-10-03 8:07 ` MSavoritias 2024-10-03 9:29 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix 2024-10-03 9:34 ` MSavoritias
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.