Hi, ------- Original Message ------- On Monday, October 23rd, 2023 at 6:18 AM, Greg Hogan <c...@greghogan.com> wrote:
> > On Tue, May 16, 2023 at 4:55 PM Csepp raingl...@riseup.net wrote: > > > Greg Hogan c...@greghogan.com writes: > > > > > I could not find documentation on this circumstance or how to resolve. > > > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one > > > can go in the $GUIX_PROFILE. > > > > > > Creating a container, the latter package overshadows the former > > > package, as below. Unclear if this is consistent. In my manifest the > > > former package overshadows the latter (I'd prefer to have parallel's > > > parallel, but by default I have sorted the listing alphabetically). Is > > > there a better way to fix this? > > > > > > Greg > > > > > > --8<---------------cut here---------------start------------->8--- > > > $ guix shell --container moreutils parallel which coreutils > > > [env]$ readlink -f `which parallel` > > > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel > > > > > > guix shell --container parallel moreutils which coreutils > > > [env]$ readlink -f $(which parallel) > > > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel > > > --8<---------------cut here---------------end--------------->8--- > > > > > > This is operating from a recent guix pull: > > > > > > --8<---------------cut here---------------start------------->8--- > > > $ guix describe > > > Generation 44 May 11 2023 17:02:53 (current) > > > guix d6f6b57 > > > repository URL: https://git.savannah.gnu.org/git/guix.git > > > branch: master > > > commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867 > > > --8<---------------cut here---------------end--------------->8--- > > > > You could create a package that just copies the contents of moreutils > > to $output, but renames some files, then include the resulting package > > in your manifest. If moreutils is not propagated from any other > > package, then you don't even have to do an input rewrite. > > > I'm still cutting my teeth on Scheme, and this looks like a simple > error, but the following from my manifest results in the error below. > The function accepts a package to inherit from and a list of files to > rename by appending the package name. This works if I change to pass > in a single string and create the list within the for-each argument. > > (define (rename-files parent-package files) > (package/inherit parent-package > (arguments > (substitute-keyword-arguments (package-arguments parent-package) > ((#:phases phases #~%standard-phases) > #~(modify-phases #$phases > (add-after 'install 'rename-files > (lambda* (#:key outputs #:allow-other-keys) > (let ((out #$output) (name #$(package-name parent-package))) > (for-each > (lambda (file) > (rename-file (string-append out "/" file) > (string-append out "/" file "-" name))) > #$files)))))))))) > > (define moreutils-decollide > (rename-files moreutils (list "bin/parallel"))) > > --8<---------------cut here---------------start------------->8--- > > starting phase `rename-files' error: in phase 'rename-files': uncaught > exception: wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") > ("bin/parallel") phase` rename-files' failed after 0.0 seconds This error is because using gexps adds an extra layer of expansion on top of normal scheme. The error is coming from the use of "#$files"... specifically in the subform "(for-each (lambda (file) ...) #$files)", #$files is replaced--in the usage example--with exactly ("bin/parallel"), resulting in: (for-each (lambda (file) ...) ("bin/parallel")) Because it is a gexp, #$file is replaced with ("bin/parallel") and then the resulting form is evaluated on the builder. Since ("bin/parallel") now looks like a function call, it tries to treat it as one. The three main options that I know of are to 1) quote the argument when calling rename-files so that "list" is first in the literal list: (rename-files moreutils '(list "bin/parallel")) 2) quote the list within the gexp: (for-each (lambda (file) ...) '#$files) 3) build the list within the gexp: (for-each (lambda (file) ...) (list #@$files) In my opinion the second option is probably the easiest and safest to work with. #1 and #3 both suffer from needing to specially craft the incoming argument to handle being evaluated twice. For #1, the argument has to be a list after being evaluated twice (the first evaluation is of the quote, the second occurs after the gexp was expanded and calls list with the string arguments). For #3, the expectation of a list is more explicit, but the argument has to evaluate to a list where all of the elements have to then evaluate to something meaningful (not too much of an issue for this case as strings evaluate to themselves). #2 should only require that the evaluated argument has a printable representation that can be read back in, which at least to me feels more natural to work with. Hope my early morning explanation helps! Cheers, Kaelyn > Backtrace: > 9 (primitive-load "/gnu/store/qrj9l194a552vpg2234xx55k76j…") > In guix/build/gnu-build-system.scm: > 908:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) > In ice-9/boot-9.scm: > 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) > In srfi/srfi-1.scm: > 634:9 6 (for-each #<procedure 7ffff5b0b140 at guix/build/gnu-b…> …) > > In ice-9/boot-9.scm: > 1752:10 5 (with-exception-handler _ _ #:unwind? _ # ) > In guix/build/gnu-build-system.scm: > 929:23 4 () > In ice-9/eval.scm: > 159:9 3 (_ #(#(#(#<directory (guile-user) 7ffff77f7c80>) (#)) …)) > > 159:9 2 (_ _) > In ice-9/boot-9.scm: > 1685:16 1 (raise-exception _ #:continuable? _) > 1685:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > Wrong type to apply: "bin/parallel" > --8<---------------cut here---------------end--------------->8---
