Help packaging R Quarto Cli

Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 1610 bytes --]

Hi,

I’m trying to package Quarto Cli ( <https://github.com/quarto-dev/quarto-cli> ), used in combination with Pandoc to publish -reproducible- scientific document : website, blog, etc.

I first think this is a classic gnu build : ./configure && make && make install BUT, there is a problem because the ./configure script bootstrap “Deno” during the run of configure.sh.

Because this download and compilation of Deno occur during ./configure.sh running, guix cannot patch the  #!/bin/bash path, so ./configure failed. Deno seems also not packaged into guix.

Do you have an idea to resolve this ? Perhaps we could try all together to do this.

I’m starting with this quarto-cli.scm :

┌────
│ (use-modules
│ (guix packages)
│ (guix download)
│ (guix build-system gnu)
│ (guix licenses)
│ )
│ 
│ (define-public quarto-cli
│   (package
│     (name "Quarto-CLI")
│     (version "1.1.251")
│     (source (origin
│               (method url-fetch)
│               (uri (string-append "https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz"))
│               (sha256
│                (base32
│                 "1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6"))))
│     (build-system gnu-build-system)
│     (synopsis "Quarto-cli")
│     (description
│      "Quarto-cli description")
│     (home-page "https://github.com/quarto-dev/quarto-cli")
│     (license gpl3+)))
│ quarto-cli
│ 
└────

To compile and fail :
guix build -f quarto-cli.scm

Best,
Sebastien RC.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Sebastien Rey-Coyrehourcq]

Le Lundi, Octobre 24, 2022 13:43 CEST, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> a écrit:

> Hi,
>
> I’m trying to package Quarto Cli ( <https://github.com/quarto-dev/quarto-cli> ), used in combination with Pandoc to publish -reproducible- scientific document : website, blog, etc.
>
> I first think this is a classic gnu build : ./configure && make && make install BUT, there is a problem because the ./configure script bootstrap “Deno” during the run of configure.sh.
>
> Because this download and compilation of Deno occur during ./configure.sh running, guix cannot patch the  #!/bin/bash path, so ./configure failed. Deno seems also not packaged into guix.
>
> Do you have an idea to resolve this ? Perhaps we could try all together to do this.
>
> I’m starting with this quarto-cli.scm :
>
> ┌────
> │ (use-modules
> │ (guix packages)
> │ (guix download)
> │ (guix build-system gnu)
> │ (guix licenses)
> │ )
> │
> │ (define-public quarto-cli
> │   (package
> │     (name "Quarto-CLI")
> │     (version "1.1.251")
> │     (source (origin
> │               (method url-fetch)
> │               (uri (string-append "https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz"))
> │               (sha256
> │                (base32
> │                 "1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6"))))
> │     (build-system gnu-build-system)
> │     (synopsis "Quarto-cli")
> │     (description
> │      "Quarto-cli description")
> │     (home-page "https://github.com/quarto-dev/quarto-cli")

> │     (license gpl3+)))
> │ quarto-cli
> │
> └────
>
> To compile and fail :
> guix build -f quarto-cli.scm
>
> Best,
> Sebastien RC.

Deno contain lot of packages dependencies actually,
here i comment all packages not packaged in rust after a simple run of guix import ...

#+BEGIN_SRC scheme

(use-modules
(guix packages)
(guix build-system cargo)
(guix download)
(guix licenses)
(gnu packages rust)
(gnu packages crates-io)
)

(define-public rust-deno-1
  (package
    (name "rust-deno")
    (version "1.26.2")
    (source (origin
              (method url-fetch)
              (uri (crate-uri "deno" version))
              (file-name (string-append name "-" version ".tar.gz"))
              (sha256
               (base32
                "1yzvdkj8sq475kfbkms1lfysjddkfwcyqhp1ggalfbk4hqhbiz29"))))
    (build-system cargo-build-system)
    (arguments
     `(#:cargo-inputs (("rust-atty" ,rust-atty-0.2)
                       ("rust-base64" ,rust-base64-0.13)
;                       ("rust-cache-control" ,rust-cache-control-0.2)

                        ("rust-chrono" ,rust-chrono-0.4)
;                       ("rust-clap" ,rust-clap-3)
;                       ("rust-clap-complete" ,rust-clap-complete-3)
;                       ("rust-clap-complete-fig" ,rust-clap-complete-fig-3)
                        ("rust-data-url" ,rust-data-url-0.1)
;                       ("rust-deno-ast" ,rust-deno-ast-0.19)
;                       ("rust-deno-broadcast-channel" ,rust-deno-broadcast-channel-0.67)
;                       ("rust-deno-cache" ,rust-deno-cache-0.5)
;                       ("rust-deno-console" ,rust-deno-console-0.73)
;                       ("rust-deno-core" ,rust-deno-core-0.155)
;                       ("rust-deno-core" ,rust-deno-core-0.155)
;                       ("rust-deno-crypto" ,rust-deno-crypto-0.87)
;                       ("rust-deno-doc" ,rust-deno-doc-0.46)
;                       ("rust-deno-emit" ,rust-deno-emit-0.9)
;                       ("rust-deno-fetch" ,rust-deno-fetch-0.96)
;                       ("rust-deno-graph" ,rust-deno-graph-0.34)
;                       ("rust-deno-lint" ,rust-deno-lint-0.33)
;                       ("rust-deno-net" ,rust-deno-net-0.65)
;                       ("rust-deno-node" ,rust-deno-node-0.10)
;                       ("rust-deno-runtime" ,rust-deno-runtime-0.81)
;                       ("rust-deno-task-shell" ,rust-deno-task-shell-0.5)
;                       ("rust-deno-url" ,rust-deno-url-0.73)
;                       ("rust-deno-web" ,rust-deno-web-0.104)
;                       ("rust-deno-webgpu" ,rust-deno-webgpu-0.74)
;                       ("rust-deno-websocket" ,rust-deno-websocket-0.78)
;                       ("rust-deno-webstorage" ,rust-deno-webstorage-0.68)
                       ("rust-dissimilar" ,rust-dissimilar-1)
;                       ("rust-dprint-plugin-json" ,rust-dprint-plugin-json-0.15)
;                       ("rust-dprint-plugin-markdown" ,rust-dprint-plugin-markdown-0.14)
;                       ("rust-dprint-plugin-typescript" ,rust-dprint-plugin-typescript-0.74)
                       ("rust-encoding-rs" ,rust-encoding-rs-0.8)
                       ("rust-env-logger" ,rust-env-logger-0.9)
;                       ("rust-eszip" ,rust-eszip-0.28)
;                       ("rust-fancy-regex" ,rust-fancy-regex-0.10)
                       ("rust-flate2" ,rust-flate2-1)
                       ("rust-fwdansi" ,rust-fwdansi-1)
;                       ("rust-glibc-version" ,rust-glibc-version-0.1)

                       ("rust-http" ,rust-http-0.2)
;                       ("rust-import-map" ,rust-import-map-0.12)
                       ("rust-indexmap" ,rust-indexmap-1)
;                       ("rust-indicatif" ,rust-indicatif-0.17)
;                       ("rust-jsonc-parser" ,rust-jsonc-parser-0.21)
;                       ("rust-junction" ,rust-junction-0.2)
                       ("rust-libc" ,rust-libc-0.2)
                       ("rust-log" ,rust-log-0.4)
;                       ("rust-mitata" ,rust-mitata-0.0.7)
;                       ("rust-monch" ,rust-monch-0.2)
;                       ("rust-napi-sym" ,rust-napi-sym-0.3)
                       ("rust-notify" ,rust-notify-5)
                       ("rust-once-cell" ,rust-once-cell-1)
                       ("rust-os-pipe" ,rust-os-pipe-1)
                       ("rust-percent-encoding" ,rust-percent-encoding-2)
                       ("rust-pin-project" ,rust-pin-project-1)
                       ("rust-rand" ,rust-rand-0.8)
                       ("rust-regex" ,rust-regex-1)
                       ("rust-regex" ,rust-regex-1)
                       ("rust-ring" ,rust-ring-0.16)
;                       ("rust-rustyline" ,rust-rustyline-10)
;                       ("rust-rustyline-derive" ,rust-rustyline-derive-0.7)
                       ("rust-semver" ,rust-semver-1)
                       ("rust-serde" ,rust-serde-1)
                       ("rust-serde" ,rust-serde-1)
                       ("rust-serde-json" ,rust-serde-json-1)
                       ("rust-serde-repr" ,rust-serde-repr-0.1)
                       ("rust-shell-escape" ,rust-shell-escape-0.1)
                       ("rust-tar" ,rust-tar-0.4)
                       ("rust-tempfile" ,rust-tempfile-3)
                       ("rust-text-size" ,rust-text-size-1)
;                       ("rust-text-lines" ,rust-text-lines-0.6)
                       ("rust-tokio" ,rust-tokio-1)
;                       ("rust-tokio-util" ,rust-tokio-util-0.7)
;                       ("rust-tower-lsp" ,rust-tower-lsp-0.17)
                       ("rust-twox-hash" ,rust-twox-hash-1)
                       ("rust-typed-arena" ,rust-typed-arena-2)
;                       ("rust-uuid" ,rust-uuid-1)
                       ("rust-walkdir" ,rust-walkdir-2)
                       ("rust-winapi" ,rust-winapi-0.3)
                       ("rust-winapi" ,rust-winapi-0.3)
                       ("rust-winres" ,rust-winres-0.1)
;                      ("rust-zstd" ,rust-zstd-0.11)
                       )
       #:cargo-development-inputs (
                                   ;("rust-deno-bench-util" ,rust-deno-bench-util-0.67)
                                   ("rust-dotenv" ,rust-dotenv-0.15)
                                   ;("rust-flaky-test" ,rust-flaky-test-0.1)
                                   ;("rust-nix" ,rust-nix-0.24)
                                   ("rust-once-cell" ,rust-once-cell-1)
                                   ("rust-os-pipe" ,rust-os-pipe-1)
                                   ("rust-pretty-assertions" ,rust-pretty-assertions-1)
                                   ;("rust-trust-dns-client" ,rust-trust-dns-client-0.22)
                                   ;("rust-trust-dns-server" ,rust-trust-dns-server-0.22))))
    (home-page "https://github.com/denoland/deno")
    (synopsis "Provides the deno executable")
    (description "This package provides the deno executable")
    (license expat)))

rust-deno-1

#+END_SRC

Re: Help packaging R Quarto Cli

[zimoun]

Hi Sébastien,

On lun., 24 oct. 2022 at 13:43, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> I’m trying to package Quarto Cli (
> <https://github.com/quarto-dev/quarto-cli> ), used in combination with
> Pandoc to publish -reproducible- scientific document : website, blog,
> etc.

Well, after a quick look I think it is not easy to package because it is
TypeScript and the story between JavaScript and Guix is not really
smooth. :-)


> I first think this is a classic gnu build : ./configure && make &&
> make install BUT, there is a problem because the ./configure script
> bootstrap “Deno” during the run of configure.sh.

Assuming “Deno“ (a modern runtime for JavaScript and TypeScript written
in Rust) is packaged by Guix, the build system for packaging Quarto
would not clear to me.


> Because this download and compilation of Deno occur during
> ./configure.sh running, guix cannot patch the  #!/bin/bash path, so
> ./configure failed. Deno seems also not packaged into guix.
>
> Do you have an idea to resolve this ? Perhaps we could try all
> together to do this.

Hum, maybe package deno. ;-)  Well, 

    guix import crate deno -r

is a starting point.  But Deno, neither Quarto, are easy to package for
Guix.


Cheers,
simon

Re: Help packaging R Quarto Cli

[Csepp]

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Sébastien,
>
> On lun., 24 oct. 2022 at 13:43, Sébastien Rey-Coyrehourcq
> <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> I’m trying to package Quarto Cli (
>> <https://github.com/quarto-dev/quarto-cli> ), used in combination with
>> Pandoc to publish -reproducible- scientific document : website, blog,
>> etc.
>
> Well, after a quick look I think it is not easy to package because it is
> TypeScript and the story between JavaScript and Guix is not really
> smooth. :-)
>
>
>> I first think this is a classic gnu build : ./configure && make &&
>> make install BUT, there is a problem because the ./configure script
>> bootstrap “Deno” during the run of configure.sh.
>
> Assuming “Deno“ (a modern runtime for JavaScript and TypeScript written
> in Rust) is packaged by Guix, the build system for packaging Quarto
> would not clear to me.
>
>
>> Because this download and compilation of Deno occur during
>> ./configure.sh running, guix cannot patch the  #!/bin/bash path, so
>> ./configure failed. Deno seems also not packaged into guix.
>>
>> Do you have an idea to resolve this ? Perhaps we could try all
>> together to do this.
>
> Hum, maybe package deno. ;-)  Well, 
>
>     guix import crate deno -r
>
> is a starting point.  But Deno, neither Quarto, are easy to package for
> Guix.
>
>
> Cheers,
> simon

There is a channel for free software that is not easily bootstrappable
that this might be suitable for:
https://github.com/guix-science/guix-science
That is where RStudio is packaged for example.

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

> Well, after a quick look I think it is not easy to package because it is
> TypeScript and the story between JavaScript and Guix is not really
> smooth. :-)

Out of curiosity - what are the problems between Guix and JS? When I
read this my first suspicion was that maybe TS is a self-hosted
language and cannot be bootstrapped. However, when I ran `guix search
typescript`, it revealed the existence of some TS->JS compiler called
'rust-swc'. So I guess problems lie somewhere else, right?

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #37: blessed Michał Tomaszek
Poznaj świętych krakowskich!  #37: błogosławiony Michał Tomaszek
https://pl.wikipedia.org/wiki/Michał_Tomaszek
-- (sig_end)


On Mon, 24 Oct 2022 19:08:26 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> Hi Sébastien,
> 
> On lun., 24 oct. 2022 at 13:43, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> 
> > I’m trying to package Quarto Cli (
> > <https://github.com/quarto-dev/quarto-cli> ), used in combination with
> > Pandoc to publish -reproducible- scientific document : website, blog,
> > etc.  
> 
> Well, after a quick look I think it is not easy to package because it is
> TypeScript and the story between JavaScript and Guix is not really
> smooth. :-)
> 
> 
> > I first think this is a classic gnu build : ./configure && make &&
> > make install BUT, there is a problem because the ./configure script
> > bootstrap “Deno” during the run of configure.sh.  
> 
> Assuming “Deno“ (a modern runtime for JavaScript and TypeScript written
> in Rust) is packaged by Guix, the build system for packaging Quarto
> would not clear to me.
> 
> 
> > Because this download and compilation of Deno occur during
> > ./configure.sh running, guix cannot patch the  #!/bin/bash path, so
> > ./configure failed. Deno seems also not packaged into guix.
> >
> > Do you have an idea to resolve this ? Perhaps we could try all
> > together to do this.  
> 
> Hum, maybe package deno. ;-)  Well, 
> 
>     guix import crate deno -r
> 
> is a starting point.  But Deno, neither Quarto, are easy to package for
> Guix.
> 
> 
> Cheers,
> simon
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[zimoun]

Hi,

On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:

> Out of curiosity - what are the problems between Guix and JS? When I
> read this my first suspicion was that maybe TS is a self-hosted
> language and cannot be bootstrapped. However, when I ran `guix search
> typescript`, it revealed the existence of some TS->JS compiler called
> 'rust-swc'. So I guess problems lie somewhere else, right?

Nothing per se.  Note that «TypeScript is a strongly typed programming
language that builds on JavaScript» and from my understanding (maybe I
am wrong?), it is hard to package Javascript for Guix because the
Javascript ecosystem is messy.  Janneke provides some explanations [1]
and I am not convinced the situation have changed since then.  Maybe I
am wrong…

1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>

Cheers,
simon

Re: Help packaging R Quarto Cli

[zimoun]

hi Sébastien,

On Mon, 24 Oct 2022 at 18:00, "Sebastien Rey-Coyrehourcq" <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Deno contain lot of packages dependencies actually, 
> here i comment all packages not packaged in rust after a simple run of guix import ...

Yeah! :-) Deno is not straightforward; “guix import crate -r deno” is
unmanageable, IMHO.

Maybe, the good start is to accept to pull a Deno “bootstrap” binary.
But it is probably not suitable for Guix proper; instead this attempt
could be part of the guix-science channel, IMHO.


Cheers,
simon

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]

> > Out of curiosity - what are the problems between Guix and JS? When I
> > read this my first suspicion was that maybe TS is a self-hosted
> > language and cannot be bootstrapped. However, when I ran `guix search
> > typescript`, it revealed the existence of some TS->JS compiler called
> > 'rust-swc'. So I guess problems lie somewhere else, right?  
> 
> Nothing per se.  Note that «TypeScript is a strongly typed programming
> language that builds on JavaScript» and from my understanding (maybe I
> am wrong?), it is hard to package Javascript for Guix because the
> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> and I am not convinced the situation have changed since then.  Maybe I
> am wrong…
> 
> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>

A few months ago (I think) I did run some code to actually check what
the dependency tree of the protocol buffers JS library (from npm) is.
The tree of runtime deps wasn't horribly big. The tree of
recursively-computed dev deps was, on the other hand, as bad as
described by Janneke or even worse... However, It seems in most cases
many of those packages designated as dev deps are not strictly needed
for actually building stuff. Some are just test dependencies. Others
were perhaps put there because developers understood "dev dependencies"
differently from how packagers understand it...

Anyway, it seems the only way to check what the situation really is is
to actually try packaging something. I'm confident it will be way
easier than it seems :)

Luckily for Sébastien, it seems quarto-cli - although written mostly in
JS/TS - has no NPM deps. Or at least I don't see any...

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #15: saint Jan Paweł II
Poznaj świętych krakowskich!  #15: święty Jan Paweł II
https://pl.wikipedia.org/wiki/Jan_Paweł_II
-- (sig_end)


On Tue, 25 Oct 2022 12:08:59 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> Hi,
> 
> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
> 
> > Out of curiosity - what are the problems between Guix and JS? When I
> > read this my first suspicion was that maybe TS is a self-hosted
> > language and cannot be bootstrapped. However, when I ran `guix search
> > typescript`, it revealed the existence of some TS->JS compiler called
> > 'rust-swc'. So I guess problems lie somewhere else, right?  
> 
> Nothing per se.  Note that «TypeScript is a strongly typed programming
> language that builds on JavaScript» and from my understanding (maybe I
> am wrong?), it is hard to package Javascript for Guix because the
> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> and I am not convinced the situation have changed since then.  Maybe I
> am wrong…
> 
> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
> 
> Cheers,
> simon
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

Hi,

I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.

My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.

I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?

Best

Wojtek Kosior <koszko@koszko.org> writes:


>> > Out of curiosity - what are the problems between Guix and JS? When I
>> > read this my first suspicion was that maybe TS is a self-hosted
>> > language and cannot be bootstrapped. However, when I ran `guix search
>> > typescript`, it revealed the existence of some TS->JS compiler called
>> > ’rust-swc’. So I guess problems lie somewhere else, right?
>>
>> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> language that builds on JavaScript» and from my understanding (maybe I
>> am wrong?), it is hard to package Javascript for Guix because the
>> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> and I am not convinced the situation have changed since then.  Maybe I
>> am wrong…
>>
>> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>
> A few months ago (I think) I did run some code to actually check what
> the dependency tree of the protocol buffers JS library (from npm) is.
> The tree of runtime deps wasn’t horribly big. The tree of
> recursively-computed dev deps was, on the other hand, as bad as
> described by Janneke or even worse… However, It seems in most cases
> many of those packages designated as dev deps are not strictly needed
> for actually building stuff. Some are just test dependencies. Others
> were perhaps put there because developers understood “dev dependencies”
> differently from how packagers understand it…
>
> Anyway, it seems the only way to check what the situation really is is
> to actually try packaging something. I’m confident it will be way
> easier than it seems :)
>
> Luckily for Sébastien, it seems quarto-cli - although written mostly in
> JS/TS - has no NPM deps. Or at least I don’t see any…
>
> Wojtek
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #15: saint Jan Paweł II
> Poznaj świętych krakowskich!  #15: święty Jan Paweł II
> <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
> – (sig_end)
>
>
> On Tue, 25 Oct 2022 12:08:59 +0200
> zimoun <zimon.toutoune@gmail.com> wrote:
>
>> Hi,
>>
>> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
>>
>> > Out of curiosity - what are the problems between Guix and JS? When I
>> > read this my first suspicion was that maybe TS is a self-hosted
>> > language and cannot be bootstrapped. However, when I ran `guix search
>> > typescript`, it revealed the existence of some TS->JS compiler called
>> > ’rust-swc’. So I guess problems lie somewhere else, right?
>>
>> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> language that builds on JavaScript» and from my understanding (maybe I
>> am wrong?), it is hard to package Javascript for Guix because the
>> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> and I am not convinced the situation have changed since then.  Maybe I
>> am wrong…
>>
>> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>>
>> Cheers,
>> simon
>>
>
>

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 5612 bytes --]

> Hi,
> 
> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
> 
> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.

Do you have wour work-in-progress in some public repo? This would make
us easier to understand your setup and would also allow more ppl to
cooperate (although unfortunately Idk if there's anyone else who's
particularly interested in deno at this particular moment).

> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?

From what I've seen, Guix package definitions are usually grouped into
modules thematically. Although until you actually try upstreaming your
work, you're not bound by any reqs and you can structure the
definitions in a way that's comfortable for you.

Also, are you adding your package by modifying the actual Guix sources?
Or by creating modules outsite of these? Perhaps this was already
metioned but I don't have previous emails on the top...

Good luck :)
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #33: blessed Antonin Bajewski
Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
https://pl.wikipedia.org/wiki/Antonin_Bajewski
-- (sig_end)


On Thu, 27 Oct 2022 09:05:52 +0200
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Hi,
> 
> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
> 
> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
> 
> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
> 
> Best
> 
> Wojtek Kosior <koszko@koszko.org> writes:
> 
> 
> >> > Out of curiosity - what are the problems between Guix and JS? When I
> >> > read this my first suspicion was that maybe TS is a self-hosted
> >> > language and cannot be bootstrapped. However, when I ran `guix search
> >> > typescript`, it revealed the existence of some TS->JS compiler called
> >> > ’rust-swc’. So I guess problems lie somewhere else, right?  
> >>
> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
> >> language that builds on JavaScript» and from my understanding (maybe I
> >> am wrong?), it is hard to package Javascript for Guix because the
> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> >> and I am not convinced the situation have changed since then.  Maybe I
> >> am wrong…
> >>
> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>  
> >
> > A few months ago (I think) I did run some code to actually check what
> > the dependency tree of the protocol buffers JS library (from npm) is.
> > The tree of runtime deps wasn’t horribly big. The tree of
> > recursively-computed dev deps was, on the other hand, as bad as
> > described by Janneke or even worse… However, It seems in most cases
> > many of those packages designated as dev deps are not strictly needed
> > for actually building stuff. Some are just test dependencies. Others
> > were perhaps put there because developers understood “dev dependencies”
> > differently from how packagers understand it…
> >
> > Anyway, it seems the only way to check what the situation really is is
> > to actually try packaging something. I’m confident it will be way
> > easier than it seems :)
> >
> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
> > JS/TS - has no NPM deps. Or at least I don’t see any…
> >
> > Wojtek
> >
> > – (sig_start)
> > website: <https://koszko.org/koszko.html>
> > PGP: <https://koszko.org/key.gpg>
> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >
> > Meet Kraków saints!           #15: saint Jan Paweł II
> > Poznaj świętych krakowskich!  #15: święty Jan Paweł II
> > <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
> > – (sig_end)
> >
> >
> > On Tue, 25 Oct 2022 12:08:59 +0200
> > zimoun <zimon.toutoune@gmail.com> wrote:
> >  
> >> Hi,
> >>
> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
> >>  
> >> > Out of curiosity - what are the problems between Guix and JS? When I
> >> > read this my first suspicion was that maybe TS is a self-hosted
> >> > language and cannot be bootstrapped. However, when I ran `guix search
> >> > typescript`, it revealed the existence of some TS->JS compiler called
> >> > ’rust-swc’. So I guess problems lie somewhere else, right?  
> >>
> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
> >> language that builds on JavaScript» and from my understanding (maybe I
> >> am wrong?), it is hard to package Javascript for Guix because the
> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> >> and I am not convinced the situation have changed since then.  Maybe I
> >> am wrong…
> >>
> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
> >>
> >> Cheers,
> >> simon
> >>  
> >
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 6625 bytes --]

Hi,

Wojtek Kosior <koszko@koszko.org> writes:

>> Hi,
>>
>> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
>>
>> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
>> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
>
> Do you have wour work-in-progress in some public repo? This would make
> us easier to understand your setup and would also allow more ppl to
> cooperate (although unfortunately Idk if there’s anyone else who’s
> particularly interested in deno at this particular moment).
>

Here we are : <https://git.sr.ht/~reyman/build-deno-script>

This is a wip python script that build an `export/' directory containing all rust module needed to compile deno (i suppose)

The deno script is localized at the root of `export/' folder

I build the modules folders, but know i don’t know how to compile all this folders correctly using correct path …
Any guile help appreciated to do that !

For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*

I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* define-module but this probably not the good way.

>> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
>
> From what I’ve seen, Guix package definitions are usually grouped into
> modules thematically. Although until you actually try upstreaming your
> work, you’re not bound by any reqs and you can structure the
> definitions in a way that’s comfortable for you.
>
> Also, are you adding your package by modifying the actual Guix sources?
> Or by creating modules outsite of these? Perhaps this was already
> metioned but I don’t have previous emails on the top…
>

If that works locally i suppose i could sent a patch with all the rust modules needed to build Deno ?

Best !
SR.

> Good luck :)
> Wojtek
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #33: blessed Antonin Bajewski
> Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
> <https://pl.wikipedia.org/wiki/Antonin_Bajewski>
> – (sig_end)
>
>
> On Thu, 27 Oct 2022 09:05:52 +0200
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Hi,
>>
>> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
>>
>> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
>> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
>>
>> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
>>
>> Best
>>
>> Wojtek Kosior <koszko@koszko.org> writes:
>>
>>
>> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >>
>> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> am wrong…
>> >>
>> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>> >
>> > A few months ago (I think) I did run some code to actually check what
>> > the dependency tree of the protocol buffers JS library (from npm) is.
>> > The tree of runtime deps wasn’t horribly big. The tree of
>> > recursively-computed dev deps was, on the other hand, as bad as
>> > described by Janneke or even worse… However, It seems in most cases
>> > many of those packages designated as dev deps are not strictly needed
>> > for actually building stuff. Some are just test dependencies. Others
>> > were perhaps put there because developers understood “dev dependencies”
>> > differently from how packagers understand it…
>> >
>> > Anyway, it seems the only way to check what the situation really is is
>> > to actually try packaging something. I’m confident it will be way
>> > easier than it seems :)
>> >
>> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
>> > JS/TS - has no NPM deps. Or at least I don’t see any…
>> >
>> > Wojtek
>> >
>> > – (sig_start)
>> > website: <https://koszko.org/koszko.html>
>> > PGP: <https://koszko.org/key.gpg>
>> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >
>> > Meet Kraków saints!           #15: saint Jan Paweł II
>> > Poznaj świętych krakowskich!  #15: święty Jan Paweł II
>> > <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
>> > – (sig_end)
>> >
>> >
>> > On Tue, 25 Oct 2022 12:08:59 +0200
>> > zimoun <zimon.toutoune@gmail.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
>> >>
>> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >>
>> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> am wrong…
>> >>
>> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>> >>
>> >> Cheers,
>> >> simon
>> >>
>> >
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 8790 bytes --]

I think I almost understand your approach. Just a quick question - what
Guix command are you using to try building? With this setup I'd try
something like

    guix shell -L ./export/ rust-deno

and then I'd put

    (define-module (rust-ecdsa-0.14 rust-ecdsa-0.14)
      #:use-module (rust-serdect-0.1 rust-serdect-0.1))

inside `./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm`. That's how guile
modules work - a module is identified by a list of symbols that match
module file's path (starting from a guile's modules root directory, in
this case the one passed via the `-L` option).

> If that works locally i suppose i could sent a patch with all the
> rust modules needed to build Deno ?

A patch would then expect the module(s) to be put under gnu/packages in
the Guix repo and then their `#:use-module` lines would need to be
modified accordingly... So you'd need to make these small adaptations
first.

Honestly, I haven't been submitting patches before and I don't know
exactly what module structure Guix devs expect. Perhaps someone else
may help you here.

Anyway, it seems right now you just have the result of running
`guix import` and you have not yet built any of those recipes? I don't
want to be pessimistic but here's a warning - there'll surely be some
fixes you'll have to make. Be prepared to dive into scheme :)

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #16: saint Jan z Dukli
Poznaj świętych krakowskich!  #16: święty Jan z Dukli
https://pl.wikipedia.org/wiki/Jan_z_Dukli
-- (sig_end)


On Fri, 28 Oct 2022 18:19:32 +0200
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Hi,
> 
> Wojtek Kosior <koszko@koszko.org> writes:
> 
> >> Hi,
> >>
> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
> >>
> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.  
> >
> > Do you have wour work-in-progress in some public repo? This would make
> > us easier to understand your setup and would also allow more ppl to
> > cooperate (although unfortunately Idk if there’s anyone else who’s
> > particularly interested in deno at this particular moment).
> >  
> 
> Here we are : <https://git.sr.ht/~reyman/build-deno-script>
> 
> This is a wip python script that build an `export/' directory containing all rust module needed to compile deno (i suppose)
> 
> The deno script is localized at the root of `export/' folder
> 
> I build the modules folders, but know i don’t know how to compile all this folders correctly using correct path …
> Any guile help appreciated to do that !
> 
> For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*
> 
> I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* define-module but this probably not the good way.
> 
> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?  
> >
> > From what I’ve seen, Guix package definitions are usually grouped into
> > modules thematically. Although until you actually try upstreaming your
> > work, you’re not bound by any reqs and you can structure the
> > definitions in a way that’s comfortable for you.
> >
> > Also, are you adding your package by modifying the actual Guix sources?
> > Or by creating modules outsite of these? Perhaps this was already
> > metioned but I don’t have previous emails on the top…
> >  
> 
> If that works locally i suppose i could sent a patch with all the rust modules needed to build Deno ?
> 
> Best !
> SR.
> 
> > Good luck :)
> > Wojtek
> >
> > – (sig_start)
> > website: <https://koszko.org/koszko.html>
> > PGP: <https://koszko.org/key.gpg>
> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >
> > Meet Kraków saints!           #33: blessed Antonin Bajewski
> > Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
> > <https://pl.wikipedia.org/wiki/Antonin_Bajewski>
> > – (sig_end)
> >
> >
> > On Thu, 27 Oct 2022 09:05:52 +0200
> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> >  
> >> Hi,
> >>
> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
> >>
> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
> >>
> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
> >>
> >> Best
> >>
> >> Wojtek Kosior <koszko@koszko.org> writes:
> >>
> >>  
> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
> >> >> > read this my first suspicion was that maybe TS is a self-hosted
> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?  
> >> >>
> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
> >> >> language that builds on JavaScript» and from my understanding (maybe I
> >> >> am wrong?), it is hard to package Javascript for Guix because the
> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> >> >> and I am not convinced the situation have changed since then.  Maybe I
> >> >> am wrong…
> >> >>
> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>  
> >> >
> >> > A few months ago (I think) I did run some code to actually check what
> >> > the dependency tree of the protocol buffers JS library (from npm) is.
> >> > The tree of runtime deps wasn’t horribly big. The tree of
> >> > recursively-computed dev deps was, on the other hand, as bad as
> >> > described by Janneke or even worse… However, It seems in most cases
> >> > many of those packages designated as dev deps are not strictly needed
> >> > for actually building stuff. Some are just test dependencies. Others
> >> > were perhaps put there because developers understood “dev dependencies”
> >> > differently from how packagers understand it…
> >> >
> >> > Anyway, it seems the only way to check what the situation really is is
> >> > to actually try packaging something. I’m confident it will be way
> >> > easier than it seems :)
> >> >
> >> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
> >> > JS/TS - has no NPM deps. Or at least I don’t see any…
> >> >
> >> > Wojtek
> >> >
> >> > – (sig_start)
> >> > website: <https://koszko.org/koszko.html>
> >> > PGP: <https://koszko.org/key.gpg>
> >> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >> >
> >> > Meet Kraków saints!           #15: saint Jan Paweł II
> >> > Poznaj świętych krakowskich!  #15: święty Jan Paweł II
> >> > <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
> >> > – (sig_end)
> >> >
> >> >
> >> > On Tue, 25 Oct 2022 12:08:59 +0200
> >> > zimoun <zimon.toutoune@gmail.com> wrote:
> >> >  
> >> >> Hi,
> >> >>
> >> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
> >> >>  
> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
> >> >> > read this my first suspicion was that maybe TS is a self-hosted
> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?  
> >> >>
> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
> >> >> language that builds on JavaScript» and from my understanding (maybe I
> >> >> am wrong?), it is hard to package Javascript for Guix because the
> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> >> >> and I am not convinced the situation have changed since then.  Maybe I
> >> >> am wrong…
> >> >>
> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
> >> >>
> >> >> Cheers,
> >> >> simon
> >> >>  
> >> >
> >> >  
> >
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 10029 bytes --]

Wojtek Kosior <koszko@koszko.org> writes:

> I think I almost understand your approach. Just a quick question - what
> Guix command are you using to try building? With this setup I’d try
> something like
>
>     guix shell -L ./export/ rust-deno
>

Actually, from export folder i try :
i try *guix build -L . -f rust-deno-1.scm*

But the module are not loaded, i don’t understand well the way guix load module it seems.

Into rust-deno-1.scm i put :

(define-module (rust-deno-1 rust-deno-1)
 #:use-module (rust-cache-control-0.2 rust-cache-control-0.2)

and into ./rust-cache-control-0.2/rust-cache-control-0.2.scm i put :

(define-module (rust-cache-control-0.2 rust-cache-control-0.2)

But any of this pass using the *guix build* command :

`no code for module (rust-cache-control-0.2 rust-cache-control-0.2)'


> and then I’d put
>
>     (define-module (rust-ecdsa-0.14 rust-ecdsa-0.14)
>       #:use-module (rust-serdect-0.1 rust-serdect-0.1))
>
> inside `./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm`. That’s how guile
> modules work - a module is identified by a list of symbols that match
> module file’s path (starting from a guile’s modules root directory, in
> this case the one passed via the `-L` option).
>
>> If that works locally i suppose i could sent a patch with all the
>> rust modules needed to build Deno ?
>
> A patch would then expect the module(s) to be put under gnu/packages in
> the Guix repo and then their `#:use-module` lines would need to be
> modified accordingly… So you’d need to make these small adaptations
> first.
>
> Honestly, I haven’t been submitting patches before and I don’t know
> exactly what module structure Guix devs expect. Perhaps someone else
> may help you here.
>
> Anyway, it seems right now you just have the result of running
> `guix import` and you have not yet built any of those recipes? I don’t
> want to be pessimistic but here’s a warning - there’ll surely be some
> fixes you’ll have to make. Be prepared to dive into scheme :)
>

I first put all the things into deno.scm, with thousand of lines, that compile a little… and i changing my mind finally …
imho the module way is perhaps less discouraging : Resolving bug modules by modules…

I push some corrections to my python script to generate good module name when i found.

Yes, i probably need some guile diving …

Best,
Sr-C.

> Best,
> Wojtek
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #16: saint Jan z Dukli
> Poznaj świętych krakowskich!  #16: święty Jan z Dukli
> <https://pl.wikipedia.org/wiki/Jan_z_Dukli>
> – (sig_end)
>
>
> On Fri, 28 Oct 2022 18:19:32 +0200
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Hi,
>>
>> Wojtek Kosior <koszko@koszko.org> writes:
>>
>> >> Hi,
>> >>
>> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
>> >>
>> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
>> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
>> >
>> > Do you have wour work-in-progress in some public repo? This would make
>> > us easier to understand your setup and would also allow more ppl to
>> > cooperate (although unfortunately Idk if there’s anyone else who’s
>> > particularly interested in deno at this particular moment).
>> >
>>
>> Here we are : <https://git.sr.ht/~reyman/build-deno-script>
>>
>> This is a wip python script that build an `export/’ directory containing all rust module needed to compile deno (i suppose)
>>
>> The deno script is localized at the root of `export/’ folder
>>
>> I build the modules folders, but know i don’t know how to compile all this folders correctly using correct path …
>> Any guile help appreciated to do that !
>>
>> For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*
>>
>> I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* define-module but this probably not the good way.
>>
>> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
>> >
>> > From what I’ve seen, Guix package definitions are usually grouped into
>> > modules thematically. Although until you actually try upstreaming your
>> > work, you’re not bound by any reqs and you can structure the
>> > definitions in a way that’s comfortable for you.
>> >
>> > Also, are you adding your package by modifying the actual Guix sources?
>> > Or by creating modules outsite of these? Perhaps this was already
>> > metioned but I don’t have previous emails on the top…
>> >
>>
>> If that works locally i suppose i could sent a patch with all the rust modules needed to build Deno ?
>>
>> Best !
>> SR.
>>
>> > Good luck :)
>> > Wojtek
>> >
>> > – (sig_start)
>> > website: <https://koszko.org/koszko.html>
>> > PGP: <https://koszko.org/key.gpg>
>> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >
>> > Meet Kraków saints!           #33: blessed Antonin Bajewski
>> > Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
>> > <https://pl.wikipedia.org/wiki/Antonin_Bajewski>
>> > – (sig_end)
>> >
>> >
>> > On Thu, 27 Oct 2022 09:05:52 +0200
>> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>> >
>> >> Hi,
>> >>
>> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
>> >>
>> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
>> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
>> >>
>> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
>> >>
>> >> Best
>> >>
>> >> Wojtek Kosior <koszko@koszko.org> writes:
>> >>
>> >>
>> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >> >>
>> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> >> am wrong…
>> >> >>
>> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>> >> >
>> >> > A few months ago (I think) I did run some code to actually check what
>> >> > the dependency tree of the protocol buffers JS library (from npm) is.
>> >> > The tree of runtime deps wasn’t horribly big. The tree of
>> >> > recursively-computed dev deps was, on the other hand, as bad as
>> >> > described by Janneke or even worse… However, It seems in most cases
>> >> > many of those packages designated as dev deps are not strictly needed
>> >> > for actually building stuff. Some are just test dependencies. Others
>> >> > were perhaps put there because developers understood “dev dependencies”
>> >> > differently from how packagers understand it…
>> >> >
>> >> > Anyway, it seems the only way to check what the situation really is is
>> >> > to actually try packaging something. I’m confident it will be way
>> >> > easier than it seems :)
>> >> >
>> >> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
>> >> > JS/TS - has no NPM deps. Or at least I don’t see any…
>> >> >
>> >> > Wojtek
>> >> >
>> >> > – (sig_start)
>> >> > website: <https://koszko.org/koszko.html>
>> >> > PGP: <https://koszko.org/key.gpg>
>> >> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >> >
>> >> > Meet Kraków saints!           #15: saint Jan Paweł II
>> >> > Poznaj świętych krakowskich!  #15: święty Jan Paweł II
>> >> > <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
>> >> > – (sig_end)
>> >> >
>> >> >
>> >> > On Tue, 25 Oct 2022 12:08:59 +0200
>> >> > zimoun <zimon.toutoune@gmail.com> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
>> >> >>
>> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >> >>
>> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> >> am wrong…
>> >> >>
>> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>> >> >>
>> >> >> Cheers,
>> >> >> simon
>> >> >>
>> >> >
>> >> >
>> >
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 12391 bytes --]

> > I think I almost understand your approach. Just a quick question - what
> > Guix command are you using to try building? With this setup I’d try
> > something like
> >
> >     guix shell -L ./export/ rust-deno
> >  
> 
> Actually, from export folder i try :
> i try *guix build -L . -f rust-deno-1.scm*

I see in your repo that rust-deno-1.scm is a module file (i.e. it has
"define-module" at the top), so you're not expected to use it with
"-f". Instead, you can rely on Guix loading it (because it is inside the
directory passed via "-L") and just do

    guix build -L . rust-deno

Where "rust-deno" is the same as in the package's "name" property.

> But the module are not loaded, i don’t understand well the way guix load module it seems.
> 
> Into rust-deno-1.scm i put :
> 
> (define-module (rust-deno-1 rust-deno-1)
>  #:use-module (rust-cache-control-0.2 rust-cache-control-0.2)
> 
> and into ./rust-cache-control-0.2/rust-cache-control-0.2.scm i put :
> 
> (define-module (rust-cache-control-0.2 rust-cache-control-0.2)
> 
> But any of this pass using the *guix build* command :
> 
> `no code for module (rust-cache-control-0.2 rust-cache-control-0.2)'

Perhaps modules can't contain periods ('.')? I'm not sure - too little
experience with scheme. I'd try giving them names without version


Wojtek


-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska
-- (sig_end)


On Fri, 28 Oct 2022 23:32:10 +0200
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Wojtek Kosior <koszko@koszko.org> writes:
> 
> > I think I almost understand your approach. Just a quick question - what
> > Guix command are you using to try building? With this setup I’d try
> > something like
> >
> >     guix shell -L ./export/ rust-deno
> >  
> 
> Actually, from export folder i try :
> i try *guix build -L . -f rust-deno-1.scm*
> 
> But the module are not loaded, i don’t understand well the way guix load module it seems.
> 
> Into rust-deno-1.scm i put :
> 
> (define-module (rust-deno-1 rust-deno-1)
>  #:use-module (rust-cache-control-0.2 rust-cache-control-0.2)
> 
> and into ./rust-cache-control-0.2/rust-cache-control-0.2.scm i put :
> 
> (define-module (rust-cache-control-0.2 rust-cache-control-0.2)
> 
> But any of this pass using the *guix build* command :
> 
> `no code for module (rust-cache-control-0.2 rust-cache-control-0.2)'
> 
> 
> > and then I’d put
> >
> >     (define-module (rust-ecdsa-0.14 rust-ecdsa-0.14)
> >       #:use-module (rust-serdect-0.1 rust-serdect-0.1))
> >
> > inside `./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm`. That’s how guile
> > modules work - a module is identified by a list of symbols that match
> > module file’s path (starting from a guile’s modules root directory, in
> > this case the one passed via the `-L` option).
> >  
> >> If that works locally i suppose i could sent a patch with all the
> >> rust modules needed to build Deno ?  
> >
> > A patch would then expect the module(s) to be put under gnu/packages in
> > the Guix repo and then their `#:use-module` lines would need to be
> > modified accordingly… So you’d need to make these small adaptations
> > first.
> >
> > Honestly, I haven’t been submitting patches before and I don’t know
> > exactly what module structure Guix devs expect. Perhaps someone else
> > may help you here.
> >
> > Anyway, it seems right now you just have the result of running
> > `guix import` and you have not yet built any of those recipes? I don’t
> > want to be pessimistic but here’s a warning - there’ll surely be some
> > fixes you’ll have to make. Be prepared to dive into scheme :)
> >  
> 
> I first put all the things into deno.scm, with thousand of lines, that compile a little… and i changing my mind finally …
> imho the module way is perhaps less discouraging : Resolving bug modules by modules…
> 
> I push some corrections to my python script to generate good module name when i found.
> 
> Yes, i probably need some guile diving …
> 
> Best,
> Sr-C.
> 
> > Best,
> > Wojtek
> >
> > – (sig_start)
> > website: <https://koszko.org/koszko.html>
> > PGP: <https://koszko.org/key.gpg>
> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >
> > Meet Kraków saints!           #16: saint Jan z Dukli
> > Poznaj świętych krakowskich!  #16: święty Jan z Dukli
> > <https://pl.wikipedia.org/wiki/Jan_z_Dukli>
> > – (sig_end)
> >
> >
> > On Fri, 28 Oct 2022 18:19:32 +0200
> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> >  
> >> Hi,
> >>
> >> Wojtek Kosior <koszko@koszko.org> writes:
> >>  
> >> >> Hi,
> >> >>
> >> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
> >> >>
> >> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
> >> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.  
> >> >
> >> > Do you have wour work-in-progress in some public repo? This would make
> >> > us easier to understand your setup and would also allow more ppl to
> >> > cooperate (although unfortunately Idk if there’s anyone else who’s
> >> > particularly interested in deno at this particular moment).
> >> >  
> >>
> >> Here we are : <https://git.sr.ht/~reyman/build-deno-script>
> >>
> >> This is a wip python script that build an `export/’ directory containing all rust module needed to compile deno (i suppose)
> >>
> >> The deno script is localized at the root of `export/’ folder
> >>
> >> I build the modules folders, but know i don’t know how to compile all this folders correctly using correct path …
> >> Any guile help appreciated to do that !
> >>
> >> For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*
> >>
> >> I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* define-module but this probably not the good way.
> >>  
> >> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?  
> >> >
> >> > From what I’ve seen, Guix package definitions are usually grouped into
> >> > modules thematically. Although until you actually try upstreaming your
> >> > work, you’re not bound by any reqs and you can structure the
> >> > definitions in a way that’s comfortable for you.
> >> >
> >> > Also, are you adding your package by modifying the actual Guix sources?
> >> > Or by creating modules outsite of these? Perhaps this was already
> >> > metioned but I don’t have previous emails on the top…
> >> >  
> >>
> >> If that works locally i suppose i could sent a patch with all the rust modules needed to build Deno ?
> >>
> >> Best !
> >> SR.
> >>  
> >> > Good luck :)
> >> > Wojtek
> >> >
> >> > – (sig_start)
> >> > website: <https://koszko.org/koszko.html>
> >> > PGP: <https://koszko.org/key.gpg>
> >> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >> >
> >> > Meet Kraków saints!           #33: blessed Antonin Bajewski
> >> > Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
> >> > <https://pl.wikipedia.org/wiki/Antonin_Bajewski>
> >> > – (sig_end)
> >> >
> >> >
> >> > On Thu, 27 Oct 2022 09:05:52 +0200
> >> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> >> >  
> >> >> Hi,
> >> >>
> >> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
> >> >>
> >> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
> >> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
> >> >>
> >> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
> >> >>
> >> >> Best
> >> >>
> >> >> Wojtek Kosior <koszko@koszko.org> writes:
> >> >>
> >> >>  
> >> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
> >> >> >> > read this my first suspicion was that maybe TS is a self-hosted
> >> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
> >> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
> >> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?  
> >> >> >>
> >> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
> >> >> >> language that builds on JavaScript» and from my understanding (maybe I
> >> >> >> am wrong?), it is hard to package Javascript for Guix because the
> >> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> >> >> >> and I am not convinced the situation have changed since then.  Maybe I
> >> >> >> am wrong…
> >> >> >>
> >> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>  
> >> >> >
> >> >> > A few months ago (I think) I did run some code to actually check what
> >> >> > the dependency tree of the protocol buffers JS library (from npm) is.
> >> >> > The tree of runtime deps wasn’t horribly big. The tree of
> >> >> > recursively-computed dev deps was, on the other hand, as bad as
> >> >> > described by Janneke or even worse… However, It seems in most cases
> >> >> > many of those packages designated as dev deps are not strictly needed
> >> >> > for actually building stuff. Some are just test dependencies. Others
> >> >> > were perhaps put there because developers understood “dev dependencies”
> >> >> > differently from how packagers understand it…
> >> >> >
> >> >> > Anyway, it seems the only way to check what the situation really is is
> >> >> > to actually try packaging something. I’m confident it will be way
> >> >> > easier than it seems :)
> >> >> >
> >> >> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
> >> >> > JS/TS - has no NPM deps. Or at least I don’t see any…
> >> >> >
> >> >> > Wojtek
> >> >> >
> >> >> > – (sig_start)
> >> >> > website: <https://koszko.org/koszko.html>
> >> >> > PGP: <https://koszko.org/key.gpg>
> >> >> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >> >> >
> >> >> > Meet Kraków saints!           #15: saint Jan Paweł II
> >> >> > Poznaj świętych krakowskich!  #15: święty Jan Paweł II
> >> >> > <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
> >> >> > – (sig_end)
> >> >> >
> >> >> >
> >> >> > On Tue, 25 Oct 2022 12:08:59 +0200
> >> >> > zimoun <zimon.toutoune@gmail.com> wrote:
> >> >> >  
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
> >> >> >>  
> >> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
> >> >> >> > read this my first suspicion was that maybe TS is a self-hosted
> >> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
> >> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
> >> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?  
> >> >> >>
> >> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
> >> >> >> language that builds on JavaScript» and from my understanding (maybe I
> >> >> >> am wrong?), it is hard to package Javascript for Guix because the
> >> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
> >> >> >> and I am not convinced the situation have changed since then.  Maybe I
> >> >> >> am wrong…
> >> >> >>
> >> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
> >> >> >>
> >> >> >> Cheers,
> >> >> >> simon
> >> >> >>  
> >> >> >
> >> >> >  
> >> >
> >> >  
> >
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 15981 bytes --]

Hi,

After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.

I push the channel to reproduce the problem here :

The rust scm repo : git.sr.ht:~reyman/rust-channel
Channel info to put into *channels.scm* : <https://paste.debian.net/1260722>
The *rust-deno.scm* file to build : <https://paste.debian.net/1260723>
The command : guix time-machine -C channels.scm – build -f rust-deno.scm

And the rust error :

—

error: failed to run custom build command for `v8 v0.49.0`

Caused by:
  process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
  — stdout
  cargo:rerun-if-changed=.gn
  cargo:rerun-if-changed=BUILD.gn
  cargo:rerun-if-changed=src/binding.cc
  cargo:rerun-if-env-changed=CCACHE
  cargo:rerun-if-env-changed=CLANG_BASE_PATH
  cargo:rerun-if-env-changed=DENO_TRYBUILD
  cargo:rerun-if-env-changed=DOCS_RS
  cargo:rerun-if-env-changed=GN
  cargo:rerun-if-env-changed=GN_ARGS
  cargo:rerun-if-env-changed=HOST
  cargo:rerun-if-env-changed=NINJA
  cargo:rerun-if-env-changed=OUT_DIR
  cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
  cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
  cargo:rerun-if-env-changed=SCCACHE
  cargo:rerun-if-env-changed=V8_FORCE_DEBUG
  cargo:rerun-if-env-changed=V8_FROM_SOURCE
  cargo:rustc-link-lib=static=rusty_v8
  download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
  static lib URL: <https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
  cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
  Downloading <https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
  Python downloader failed, trying with curl.

  — stderr
  thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish…
error: build failed
error: in phase ’build’: uncaught exception:
%exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
phase `build’ failed after 105.5 seconds
command “cargo” “build” “–release” failed with status 101
builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed


Wojtek Kosior <koszko@koszko.org> writes:


>> > I think I almost understand your approach. Just a quick question - what
>> > Guix command are you using to try building? With this setup I’d try
>> > something like
>> >
>> >     guix shell -L ./export/ rust-deno
>> >
>>
>> Actually, from export folder i try :
>> i try *guix build -L . -f rust-deno-1.scm*
>
> I see in your repo that rust-deno-1.scm is a module file (i.e. it has
> “define-module” at the top), so you’re not expected to use it with
> “-f”. Instead, you can rely on Guix loading it (because it is inside the
> directory passed via “-L”) and just do
>
>     guix build -L . rust-deno
>
> Where “rust-deno” is the same as in the package’s “name” property.
>
>> But the module are not loaded, i don’t understand well the way guix load module it seems.
>>
>> Into rust-deno-1.scm i put :
>>
>> (define-module (rust-deno-1 rust-deno-1)
>>  #:use-module (rust-cache-control-0.2 rust-cache-control-0.2)
>>
>> and into ./rust-cache-control-0.2/rust-cache-control-0.2.scm i put :
>>
>> (define-module (rust-cache-control-0.2 rust-cache-control-0.2)
>>
>> But any of this pass using the *guix build* command :
>>
>> `no code for module (rust-cache-control-0.2 rust-cache-control-0.2)’
>
> Perhaps modules can’t contain periods (’.’)? I’m not sure - too little
> experience with scheme. I’d try giving them names without version
>
>
> Wojtek
>
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
> – (sig_end)
>
>
> On Fri, 28 Oct 2022 23:32:10 +0200
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Wojtek Kosior <koszko@koszko.org> writes:
>>
>> > I think I almost understand your approach. Just a quick question - what
>> > Guix command are you using to try building? With this setup I’d try
>> > something like
>> >
>> >     guix shell -L ./export/ rust-deno
>> >
>>
>> Actually, from export folder i try :
>> i try *guix build -L . -f rust-deno-1.scm*
>>
>> But the module are not loaded, i don’t understand well the way guix load module it seems.
>>
>> Into rust-deno-1.scm i put :
>>
>> (define-module (rust-deno-1 rust-deno-1)
>>  #:use-module (rust-cache-control-0.2 rust-cache-control-0.2)
>>
>> and into ./rust-cache-control-0.2/rust-cache-control-0.2.scm i put :
>>
>> (define-module (rust-cache-control-0.2 rust-cache-control-0.2)
>>
>> But any of this pass using the *guix build* command :
>>
>> `no code for module (rust-cache-control-0.2 rust-cache-control-0.2)’
>>
>>
>> > and then I’d put
>> >
>> >     (define-module (rust-ecdsa-0.14 rust-ecdsa-0.14)
>> >       #:use-module (rust-serdect-0.1 rust-serdect-0.1))
>> >
>> > inside `./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm`. That’s how guile
>> > modules work - a module is identified by a list of symbols that match
>> > module file’s path (starting from a guile’s modules root directory, in
>> > this case the one passed via the `-L` option).
>> >
>> >> If that works locally i suppose i could sent a patch with all the
>> >> rust modules needed to build Deno ?
>> >
>> > A patch would then expect the module(s) to be put under gnu/packages in
>> > the Guix repo and then their `#:use-module` lines would need to be
>> > modified accordingly… So you’d need to make these small adaptations
>> > first.
>> >
>> > Honestly, I haven’t been submitting patches before and I don’t know
>> > exactly what module structure Guix devs expect. Perhaps someone else
>> > may help you here.
>> >
>> > Anyway, it seems right now you just have the result of running
>> > `guix import` and you have not yet built any of those recipes? I don’t
>> > want to be pessimistic but here’s a warning - there’ll surely be some
>> > fixes you’ll have to make. Be prepared to dive into scheme :)
>> >
>>
>> I first put all the things into deno.scm, with thousand of lines, that compile a little… and i changing my mind finally …
>> imho the module way is perhaps less discouraging : Resolving bug modules by modules…
>>
>> I push some corrections to my python script to generate good module name when i found.
>>
>> Yes, i probably need some guile diving …
>>
>> Best,
>> Sr-C.
>>
>> > Best,
>> > Wojtek
>> >
>> > – (sig_start)
>> > website: <https://koszko.org/koszko.html>
>> > PGP: <https://koszko.org/key.gpg>
>> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >
>> > Meet Kraków saints!           #16: saint Jan z Dukli
>> > Poznaj świętych krakowskich!  #16: święty Jan z Dukli
>> > <https://pl.wikipedia.org/wiki/Jan_z_Dukli>
>> > – (sig_end)
>> >
>> >
>> > On Fri, 28 Oct 2022 18:19:32 +0200
>> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>> >
>> >> Hi,
>> >>
>> >> Wojtek Kosior <koszko@koszko.org> writes:
>> >>
>> >> >> Hi,
>> >> >>
>> >> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
>> >> >>
>> >> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
>> >> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
>> >> >
>> >> > Do you have wour work-in-progress in some public repo? This would make
>> >> > us easier to understand your setup and would also allow more ppl to
>> >> > cooperate (although unfortunately Idk if there’s anyone else who’s
>> >> > particularly interested in deno at this particular moment).
>> >> >
>> >>
>> >> Here we are : <https://git.sr.ht/~reyman/build-deno-script>
>> >>
>> >> This is a wip python script that build an `export/’ directory containing all rust module needed to compile deno (i suppose)
>> >>
>> >> The deno script is localized at the root of `export/’ folder
>> >>
>> >> I build the modules folders, but know i don’t know how to compile all this folders correctly using correct path …
>> >> Any guile help appreciated to do that !
>> >>
>> >> For example, the module *./export/rust-ecdsa-0.14/rust-ecdsa-0.14.scm* need a module localized to *./export/rust-serdect-0.1/rust-serdect-0.1.scm*
>> >>
>> >> I simply try *#:use-module (../rust-serdect-01)* in *rust-ecdsa-0.14* define-module but this probably not the good way.
>> >>
>> >> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
>> >> >
>> >> > From what I’ve seen, Guix package definitions are usually grouped into
>> >> > modules thematically. Although until you actually try upstreaming your
>> >> > work, you’re not bound by any reqs and you can structure the
>> >> > definitions in a way that’s comfortable for you.
>> >> >
>> >> > Also, are you adding your package by modifying the actual Guix sources?
>> >> > Or by creating modules outsite of these? Perhaps this was already
>> >> > metioned but I don’t have previous emails on the top…
>> >> >
>> >>
>> >> If that works locally i suppose i could sent a patch with all the rust modules needed to build Deno ?
>> >>
>> >> Best !
>> >> SR.
>> >>
>> >> > Good luck :)
>> >> > Wojtek
>> >> >
>> >> > – (sig_start)
>> >> > website: <https://koszko.org/koszko.html>
>> >> > PGP: <https://koszko.org/key.gpg>
>> >> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >> >
>> >> > Meet Kraków saints!           #33: blessed Antonin Bajewski
>> >> > Poznaj świętych krakowskich!  #33: błogosławiony Antonin Bajewski
>> >> > <https://pl.wikipedia.org/wiki/Antonin_Bajewski>
>> >> > – (sig_end)
>> >> >
>> >> >
>> >> > On Thu, 27 Oct 2022 09:05:52 +0200
>> >> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> I continue the packaging using guix import crate, this is a slow process, but everything goes well at this time.
>> >> >>
>> >> >> My file deno.scm contain 6000 line, with all packages imported, this is a problem because i need to remove duplicate.
>> >> >> The best way was probably to export all `(define public method … )`  into a folder with corresponding library.scm.
>> >> >>
>> >> >> I need to create a module by package do you thing ? and after that import all the package using `use-modules` ?
>> >> >>
>> >> >> Best
>> >> >>
>> >> >> Wojtek Kosior <koszko@koszko.org> writes:
>> >> >>
>> >> >>
>> >> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> >> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >> >> >>
>> >> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> >> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> >> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> >> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> >> >> am wrong…
>> >> >> >>
>> >> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>> >> >> >
>> >> >> > A few months ago (I think) I did run some code to actually check what
>> >> >> > the dependency tree of the protocol buffers JS library (from npm) is.
>> >> >> > The tree of runtime deps wasn’t horribly big. The tree of
>> >> >> > recursively-computed dev deps was, on the other hand, as bad as
>> >> >> > described by Janneke or even worse… However, It seems in most cases
>> >> >> > many of those packages designated as dev deps are not strictly needed
>> >> >> > for actually building stuff. Some are just test dependencies. Others
>> >> >> > were perhaps put there because developers understood “dev dependencies”
>> >> >> > differently from how packagers understand it…
>> >> >> >
>> >> >> > Anyway, it seems the only way to check what the situation really is is
>> >> >> > to actually try packaging something. I’m confident it will be way
>> >> >> > easier than it seems :)
>> >> >> >
>> >> >> > Luckily for Sébastien, it seems quarto-cli - although written mostly in
>> >> >> > JS/TS - has no NPM deps. Or at least I don’t see any…
>> >> >> >
>> >> >> > Wojtek
>> >> >> >
>> >> >> > – (sig_start)
>> >> >> > website: <https://koszko.org/koszko.html>
>> >> >> > PGP: <https://koszko.org/key.gpg>
>> >> >> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >> >> >
>> >> >> > Meet Kraków saints!           #15: saint Jan Paweł II
>> >> >> > Poznaj świętych krakowskich!  #15: święty Jan Paweł II
>> >> >> > <https://pl.wikipedia.org/wiki/Jan_Paweł_II>
>> >> >> > – (sig_end)
>> >> >> >
>> >> >> >
>> >> >> > On Tue, 25 Oct 2022 12:08:59 +0200
>> >> >> > zimoun <zimon.toutoune@gmail.com> wrote:
>> >> >> >
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via <help-guix@gnu.org> wrote:
>> >> >> >>
>> >> >> >> > Out of curiosity - what are the problems between Guix and JS? When I
>> >> >> >> > read this my first suspicion was that maybe TS is a self-hosted
>> >> >> >> > language and cannot be bootstrapped. However, when I ran `guix search
>> >> >> >> > typescript`, it revealed the existence of some TS->JS compiler called
>> >> >> >> > ’rust-swc’. So I guess problems lie somewhere else, right?
>> >> >> >>
>> >> >> >> Nothing per se.  Note that «TypeScript is a strongly typed programming
>> >> >> >> language that builds on JavaScript» and from my understanding (maybe I
>> >> >> >> am wrong?), it is hard to package Javascript for Guix because the
>> >> >> >> Javascript ecosystem is messy.  Janneke provides some explanations [1]
>> >> >> >> and I am not convinced the situation have changed since then.  Maybe I
>> >> >> >> am wrong…
>> >> >> >>
>> >> >> >> 1: <https://yhetil.org/guix/87fudzndu7.fsf@gnu.org>
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >> simon
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 4771 bytes --]

> Hi,
> 
> After some day of packaging rust crate, i progress and deno start to
> compile … but after 1min i have this error when cargo start compiling
> *rust-v8-0.49* . Any rust + guix help appreciated.

Your determination is extraordinary :)

> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Have you tried doing exactly this - setting the variable for the build
command?

Nonetheless, a quick glance at the error you posted makes me believe
Deno's build process involves downloading precompiled binary of certain
"librusty_v8". Guix builder of course blocks network access for builds,
hence the failure.

It this is indeed the case, the librusty static lib dep must be
packaged as well (if it isn't already) and Deno should then be told to
use that instead of downloading anything.

Disclaimer:
I have never built rust programs ;)

Anyway, good luck!

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #18: blessed Józef Kowalski
Poznaj świętych krakowskich!  #18: błogosławiony Józef Kowalski
https://pl.wikipedia.org/wiki/Józef_Kowalski_(duchowny)
-- (sig_end)


On Mon, 14 Nov 2022 23:30:47 +0100
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Hi,
> 
> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
> 
> I push the channel to reproduce the problem here :
> 
> The rust scm repo : git.sr.ht:~reyman/rust-channel
> Channel info to put into *channels.scm* : <https://paste.debian.net/1260722>
> The *rust-deno.scm* file to build : <https://paste.debian.net/1260723>
> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
> 
> And the rust error :
> 
> —
> 
> error: failed to run custom build command for `v8 v0.49.0`
> 
> Caused by:
>   process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>   — stdout
>   cargo:rerun-if-changed=.gn
>   cargo:rerun-if-changed=BUILD.gn
>   cargo:rerun-if-changed=src/binding.cc
>   cargo:rerun-if-env-changed=CCACHE
>   cargo:rerun-if-env-changed=CLANG_BASE_PATH
>   cargo:rerun-if-env-changed=DENO_TRYBUILD
>   cargo:rerun-if-env-changed=DOCS_RS
>   cargo:rerun-if-env-changed=GN
>   cargo:rerun-if-env-changed=GN_ARGS
>   cargo:rerun-if-env-changed=HOST
>   cargo:rerun-if-env-changed=NINJA
>   cargo:rerun-if-env-changed=OUT_DIR
>   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>   cargo:rerun-if-env-changed=SCCACHE
>   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>   cargo:rerun-if-env-changed=V8_FROM_SOURCE
>   cargo:rustc-link-lib=static=rusty_v8
>   download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>   static lib URL: <https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>   cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>   Downloading <https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>   Python downloader failed, trying with curl.
> 
>   — stderr
>   thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> warning: build failed, waiting for other jobs to finish…
> error: build failed
> error: in phase ’build’: uncaught exception:
> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
> phase `build’ failed after 105.5 seconds
> command “cargo” “build” “–release” failed with status 101
> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3830 bytes --]

On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:
> Hi,
> 
> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
> 
> I push the channel to reproduce the problem here :
> 
> The rust scm repo : git.sr.ht:~reyman/rust-channel
> Channel info to put into *channels.scm* : <https://paste.debian.net/1260722>
> The *rust-deno.scm* file to build : <https://paste.debian.net/1260723>
> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
> 
> And the rust error :
> 
> —
> 
> error: failed to run custom build command for `v8 v0.49.0`
> 
> Caused by:
>   process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>   — stdout
>   cargo:rerun-if-changed=.gn
>   cargo:rerun-if-changed=BUILD.gn
>   cargo:rerun-if-changed=src/binding.cc
>   cargo:rerun-if-env-changed=CCACHE
>   cargo:rerun-if-env-changed=CLANG_BASE_PATH
>   cargo:rerun-if-env-changed=DENO_TRYBUILD
>   cargo:rerun-if-env-changed=DOCS_RS
>   cargo:rerun-if-env-changed=GN
>   cargo:rerun-if-env-changed=GN_ARGS
>   cargo:rerun-if-env-changed=HOST
>   cargo:rerun-if-env-changed=NINJA
>   cargo:rerun-if-env-changed=OUT_DIR
>   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>   cargo:rerun-if-env-changed=SCCACHE
>   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>   cargo:rerun-if-env-changed=V8_FROM_SOURCE
>   cargo:rustc-link-lib=static=rusty_v8
>   download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>   static lib URL: <https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>   cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>   Downloading <https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>   Python downloader failed, trying with curl.

Looks like you need to patch rust-v8-0.49 to not try to download
librusty_v8_release... but instead you'll have to build it from source
and let it know where to find it.

>   — stderr
>   thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> warning: build failed, waiting for other jobs to finish…
> error: build failed
> error: in phase ’build’: uncaught exception:
> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
> phase `build’ failed after 105.5 seconds
> command “cargo” “build” “–release” failed with status 101
> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Help packaging R Quarto Cli

[Sebastien Rey-Coyrehourcq]

Hi,

You're both right, seems there is a flag to skip binary downloading and 
compile the V8 lib.

 From the githubpage (https://github.com/denoland/rusty_v8) : "V8 is 
very large and takes a long time to compile. Many users will prefer to 
use a prebuilt version of V8. We publish static libs for every version 
of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.

Binaries builds are turned on by default: |cargo build| will initiate a 
download from github to get the static lib. To disable this build using 
the |V8_FROM_SOURCE| environmental variable.

When making changes to rusty_v8 itself, it should be tested by build 
from source. The CI always builds from source"

So, my packaging friend :), what's the best way to push an "export 
V8_FROM_SOURCE=1" or something like that into my rust-deno.scm ?

Best,

SR

Le 15/11/2022 à 08:58, Efraim Flashner a écrit :
> On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:
>> Hi,
>>
>> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
>>
>> I push the channel to reproduce the problem here :
>>
>> The rust scm repo : git.sr.ht:~reyman/rust-channel
>> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
>> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
>> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
>>
>> And the rust error :
>>
>> —
>>
>> error: failed to run custom build command for `v8 v0.49.0`
>>
>> Caused by:
>>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>>    — stdout
>>    cargo:rerun-if-changed=.gn
>>    cargo:rerun-if-changed=BUILD.gn
>>    cargo:rerun-if-changed=src/binding.cc
>>    cargo:rerun-if-env-changed=CCACHE
>>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
>>    cargo:rerun-if-env-changed=DENO_TRYBUILD
>>    cargo:rerun-if-env-changed=DOCS_RS
>>    cargo:rerun-if-env-changed=GN
>>    cargo:rerun-if-env-changed=GN_ARGS
>>    cargo:rerun-if-env-changed=HOST
>>    cargo:rerun-if-env-changed=NINJA
>>    cargo:rerun-if-env-changed=OUT_DIR
>>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>>    cargo:rerun-if-env-changed=SCCACHE
>>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
>>    cargo:rustc-link-lib=static=rusty_v8
>>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>>    Python downloader failed, trying with curl.
> Looks like you need to patch rust-v8-0.49 to not try to download
> librusty_v8_release... but instead you'll have to build it from source
> and let it know where to find it.
>
>>    — stderr
>>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
>> warning: build failed, waiting for other jobs to finish…
>> error: build failed
>> error: in phase ’build’: uncaught exception:
>> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
>> phase `build’ failed after 105.5 seconds
>> command “cargo” “build” “–release” failed with status 101
>> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
>> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
>> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
>> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed
>

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 6599 bytes --]

> Hi,
> 
> You're both right, seems there is a flag to skip binary downloading and 
> compile the V8 lib.
> 
> [...]

Good to see you found it :)

> So, my packaging friend :), what's the best way to push an "export 
> V8_FROM_SOURCE=1" or something like that into my rust-deno.scm ?
> 
> Best,
> 
> SR

When I first read your question, I did not know the exact function. But
I knew where to look. So I thought I'd better share my way of learning
rather than just the solution ;)

I started with

    grep -R 'export' ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less

That showed a lot of results. I noticed a line like this

> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:             (setenv "HOME" (getcwd)) ;; cmake needs this to export modules

Thought it might be the thing I was looking for, so I did

    less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm

and navigated to this line. This seems to be it. The (setenv) function.
Can be used as from a modified packaging phase function (as you can see
in engineering.scm).

Hope I helped. Good luck once again!

W.

P.S. Make sure you know some 'less' shortcuts if you're going to do
     things this way. It cad speed things up ^^

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska
-- (sig_end)


On Wed, 16 Nov 2022 21:38:47 +0100
Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Hi,
> 
> You're both right, seems there is a flag to skip binary downloading and 
> compile the V8 lib.
> 
>  From the githubpage (https://github.com/denoland/rusty_v8) : "V8 is 
> very large and takes a long time to compile. Many users will prefer to 
> use a prebuilt version of V8. We publish static libs for every version 
> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
> 
> Binaries builds are turned on by default: |cargo build| will initiate a 
> download from github to get the static lib. To disable this build using 
> the |V8_FROM_SOURCE| environmental variable.
> 
> When making changes to rusty_v8 itself, it should be tested by build 
> from source. The CI always builds from source"
> 
> So, my packaging friend :), what's the best way to push an "export 
> V8_FROM_SOURCE=1" or something like that into my rust-deno.scm ?
> 
> Best,
> 
> SR
> 
> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :
> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:  
> >> Hi,
> >>
> >> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
> >>
> >> I push the channel to reproduce the problem here :
> >>
> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
> >>
> >> And the rust error :
> >>
> >> —
> >>
> >> error: failed to run custom build command for `v8 v0.49.0`
> >>
> >> Caused by:
> >>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
> >>    — stdout
> >>    cargo:rerun-if-changed=.gn
> >>    cargo:rerun-if-changed=BUILD.gn
> >>    cargo:rerun-if-changed=src/binding.cc
> >>    cargo:rerun-if-env-changed=CCACHE
> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
> >>    cargo:rerun-if-env-changed=DOCS_RS
> >>    cargo:rerun-if-env-changed=GN
> >>    cargo:rerun-if-env-changed=GN_ARGS
> >>    cargo:rerun-if-env-changed=HOST
> >>    cargo:rerun-if-env-changed=NINJA
> >>    cargo:rerun-if-env-changed=OUT_DIR
> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
> >>    cargo:rerun-if-env-changed=SCCACHE
> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
> >>    cargo:rustc-link-lib=static=rusty_v8
> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
> >>    Python downloader failed, trying with curl.  
> > Looks like you need to patch rust-v8-0.49 to not try to download
> > librusty_v8_release... but instead you'll have to build it from source
> > and let it know where to find it.
> >  
> >>    — stderr
> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> >> warning: build failed, waiting for other jobs to finish…
> >> error: build failed
> >> error: in phase ’build’: uncaught exception:
> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
> >> phase `build’ failed after 105.5 seconds
> >> command “cargo” “build” “–release” failed with status 101
> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed  
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 9488 bytes --]

Hi,

Thanks a lot, that helps me to make one more step :)

I set :

┌────
│     (arguments
│         `(#:phases
│            (modify-phases %standard-phases
│          (add-before 'configure 'set-source
│            (lambda _
│              (setenv "V8_FROM_SOURCE" "1")
│              (setenv "RUST_BACKTRACE" "1")
│              (setenv "CLANG_BASE_PATH" (getenv "CMAKE_PREFIX_PATH"))
│              #t)))
└────

I also try C_INCLUDE_PATH

and native input :

┌────
│ 	(native-inputs (list ninja gn clang-toolchain ccache clang))
└────

I have now another problem during compilation of v8, i don’t understand why “clang” path is not well recognized by the buildscript, test is defined here :

<https://github.com/denoland/rusty_v8/blob/main/build.rs#L517>

The backtrace :

error: failed to run custom build command for `v8 v0.49.0`

Caused by:
  process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
  — stdout
  cargo:rerun-if-changed=.gn
  cargo:rerun-if-changed=BUILD.gn
  cargo:rerun-if-changed=src/binding.cc
  cargo:rerun-if-env-changed=CCACHE
  cargo:rerun-if-env-changed=CLANG_BASE_PATH
  cargo:rerun-if-env-changed=DENO_TRYBUILD
  cargo:rerun-if-env-changed=DOCS_RS
  cargo:rerun-if-env-changed=GN
  cargo:rerun-if-env-changed=GN_ARGS
  cargo:rerun-if-env-changed=HOST
  cargo:rerun-if-env-changed=NINJA
  cargo:rerun-if-env-changed=OUT_DIR
  cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
  cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
  cargo:rerun-if-env-changed=SCCACHE
  cargo:rerun-if-env-changed=V8_FORCE_DEBUG
  cargo:rerun-if-env-changed=V8_FROM_SOURCE
  cargo:rustc-link-lib=static=rusty_v8
  using Chromiums clang
  clang_base_path /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/clang

— stderr
thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:537:6
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: core::result::Result<T,E>::unwrap
   4: build_script_build::clang_download
   5: build_script_build::build_v8
   6: build_script_build::main
   7: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Best,


Wojtek Kosior <koszko@koszko.org> writes:

>> Hi,
>>
>> You’re both right, seems there is a flag to skip binary downloading and
>> compile the V8 lib.
>>
>> […]
>
> Good to see you found it :)
>
>> So, my packaging friend :), what’s the best way to push an “export
>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>>
>> Best,
>>
>> SR
>
> When I first read your question, I did not know the exact function. But
> I knew where to look. So I thought I’d better share my way of learning
> rather than just the solution ;)
>
> I started with
>
>     grep -R ’export’ ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less
>
> That showed a lot of results. I noticed a line like this
>
>> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:             (setenv “HOME” (getcwd)) ;; cmake needs this to export modules
>
> Thought it might be the thing I was looking for, so I did
>
>     less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm
>
> and navigated to this line. This seems to be it. The (setenv) function.
> Can be used as from a modified packaging phase function (as you can see
> in engineering.scm).
>
> Hope I helped. Good luck once again!
>
> W.
>
> P.S. Make sure you know some ’less’ shortcuts if you’re going to do
>      things this way. It cad speed things up ^^
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
> – (sig_end)
>
>
> On Wed, 16 Nov 2022 21:38:47 +0100
> Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Hi,
>>
>> You’re both right, seems there is a flag to skip binary downloading and
>> compile the V8 lib.
>>
>>  From the githubpage (<https://github.com/denoland/rusty_v8>) : “V8 is
>> very large and takes a long time to compile. Many users will prefer to
>> use a prebuilt version of V8. We publish static libs for every version
>> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
>>
>> Binaries builds are turned on by default: |cargo build| will initiate a
>> download from github to get the static lib. To disable this build using
>> the |V8_FROM_SOURCE| environmental variable.
>>
>> When making changes to rusty_v8 itself, it should be tested by build
>> from source. The CI always builds from source”
>>
>> So, my packaging friend :), what’s the best way to push an “export
>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>>
>> Best,
>>
>> SR
>>
>> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :
>> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:
>> >> Hi,
>> >>
>> >> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
>> >>
>> >> I push the channel to reproduce the problem here :
>> >>
>> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
>> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
>> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
>> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
>> >>
>> >> And the rust error :
>> >>
>> >> —
>> >>
>> >> error: failed to run custom build command for `v8 v0.49.0`
>> >>
>> >> Caused by:
>> >>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>> >>    — stdout
>> >>    cargo:rerun-if-changed=.gn
>> >>    cargo:rerun-if-changed=BUILD.gn
>> >>    cargo:rerun-if-changed=src/binding.cc
>> >>    cargo:rerun-if-env-changed=CCACHE
>> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
>> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
>> >>    cargo:rerun-if-env-changed=DOCS_RS
>> >>    cargo:rerun-if-env-changed=GN
>> >>    cargo:rerun-if-env-changed=GN_ARGS
>> >>    cargo:rerun-if-env-changed=HOST
>> >>    cargo:rerun-if-env-changed=NINJA
>> >>    cargo:rerun-if-env-changed=OUT_DIR
>> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>> >>    cargo:rerun-if-env-changed=SCCACHE
>> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
>> >>    cargo:rustc-link-lib=static=rusty_v8
>> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>> >>    Python downloader failed, trying with curl.
>> > Looks like you need to patch rust-v8-0.49 to not try to download
>> > librusty_v8_release… but instead you’ll have to build it from source
>> > and let it know where to find it.
>> >
>> >>    — stderr
>> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
>> >> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
>> >> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
>> >> warning: build failed, waiting for other jobs to finish…
>> >> error: build failed
>> >> error: in phase ’build’: uncaught exception:
>> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
>> >> phase `build’ failed after 105.5 seconds
>> >> command “cargo” “build” “–release” failed with status 101
>> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
>> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
>> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
>> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 12462 bytes --]

Hi,

After two weeks of suffering and pain with this complex rust packaging, and thanks to people on the libera #guix chat, my “rust packaging adventure” is near ending… at least with deno, i see quarto after that…

Everything compile by parts, and i need a final help to merge things.

I only have a problem at `testing-phase', with a local rust package defined on Deno `/test_util' folder. This package is not published at all on crates.io and it’s needed at test-phase…

This nested crate package is not detected/compiled by actual `cargo-build-system', so i decide to package it myself , as `rust-deno-test-util-0.1.0'

I tested and this crate compile well, with two derivation :

• `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/'
• `/gnu/store/zp5flzykz7y5n35kqrlryqkynvrvcw3z-rust-deno-test-util-0.1.0.drv'

`/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/'  contain the test_util-0.1.0.crate

So … i added this *.scm* to my *deno/deno-dep* list of package in the *rust-channel* needed by deno to compile :
<https://git.sr.ht/~reyman/rust-channel/tree/543fee4cc3626ae27da5b41a7884cecb71b9dcf8/item/deno-dep/rust-deno-test-util-0-1-0.scm>

*My problem is simple?* i added this crate as a dependency of my main `rust-deno.scm' :
• `#:use-module (deno-dep rust-deno-test-util-0-1-0)'
• `#:cargo-development-inputs `((("rust-deno-test-util", rust-deno-test-util-0.1.0) ... )'

BUT BUT BUT … rust-deno-test-util is not found and not added to `/guix-vendor' during deno crate retrieval, so there is a problem somewhere during packaging retrieval from local `/gnu/store'. I found in the log that

`/gnu/store/8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/'  contain the sources and not a `tar.gz' like others crates. I suppose this is part of the problem, but i don’t know how to solve that.

See by yourself using :

guix time-machine -C channels.scm – build -f rust-deno.scm

that return :

error: no matching package named `deno_test_util` found

**Info to reproduce**

• All these package needed by Deno are defined into my-rust channel here : <https://git.sr.ht/~reyman/rust-channel>
• The building and channel scm needed to build deno are here : <https://git.sr.ht/~reyman/build-deno-guix>
• /Final Warning :/ Deno build (outside rust build) take at least 2 hours on my machine, rusty-v8 is huge and take itself ~30 to 45 minutes.

Any *final* help appreciated !

Best ,
Sébastien Rey-Coyrehourcq


Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:

>
> Hi,
>
> Thanks a lot, that helps me to make one more step :)
>
> I set :
>
> ┌────
> │     (arguments
> │         `(#:phases
> │            (modify-phases %standard-phases
> │          (add-before ’configure ’set-source
> │            (lambda _
> │              (setenv “V8_FROM_SOURCE” “1”)
> │              (setenv “RUST_BACKTRACE” “1”)
> │              (setenv “CLANG_BASE_PATH” (getenv “CMAKE_PREFIX_PATH”))
> │              #t)))
> └────
>
> I also try C_INCLUDE_PATH
>
> and native input :
>
> ┌────
> │ 	(native-inputs (list ninja gn clang-toolchain ccache clang))
> └────
>
> I have now another problem during compilation of v8, i don’t understand why “clang” path is not well recognized by the buildscript, test is defined here :
>
> <https://github.com/denoland/rusty_v8/blob/main/build.rs#L517>
>
> The backtrace :
>
> error: failed to run custom build command for `v8 v0.49.0`
>
> Caused by:
>   process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>   — stdout
>   cargo:rerun-if-changed=.gn
>   cargo:rerun-if-changed=BUILD.gn
>   cargo:rerun-if-changed=src/binding.cc
>   cargo:rerun-if-env-changed=CCACHE
>   cargo:rerun-if-env-changed=CLANG_BASE_PATH
>   cargo:rerun-if-env-changed=DENO_TRYBUILD
>   cargo:rerun-if-env-changed=DOCS_RS
>   cargo:rerun-if-env-changed=GN
>   cargo:rerun-if-env-changed=GN_ARGS
>   cargo:rerun-if-env-changed=HOST
>   cargo:rerun-if-env-changed=NINJA
>   cargo:rerun-if-env-changed=OUT_DIR
>   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>   cargo:rerun-if-env-changed=SCCACHE
>   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>   cargo:rerun-if-env-changed=V8_FROM_SOURCE
>   cargo:rustc-link-lib=static=rusty_v8
>   using Chromiums clang
>   clang_base_path /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/clang
>
> — stderr
> thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:537:6
> stack backtrace:
>    0: rust_begin_unwind
>    1: core::panicking::panic_fmt
>    2: core::result::unwrap_failed
>    3: core::result::Result<T,E>::unwrap
>    4: build_script_build::clang_download
>    5: build_script_build::build_v8
>    6: build_script_build::main
>    7: core::ops::function::FnOnce::call_once
> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
>
> Best,
>
>
> Wojtek Kosior <koszko@koszko.org> writes:
>
>>> Hi,
>>>
>>> You’re both right, seems there is a flag to skip binary downloading and
>>> compile the V8 lib.
>>>
>>> […]
>>
>> Good to see you found it :)
>>
>>> So, my packaging friend :), what’s the best way to push an “export
>>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>>>
>>> Best,
>>>
>>> SR
>>
>> When I first read your question, I did not know the exact function. But
>> I knew where to look. So I thought I’d better share my way of learning
>> rather than just the solution ;)
>>
>> I started with
>>
>>     grep -R ’export’ ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less
>>
>> That showed a lot of results. I noticed a line like this
>>
>>> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:             (setenv “HOME” (getcwd)) ;; cmake needs this to export modules
>>
>> Thought it might be the thing I was looking for, so I did
>>
>>     less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm
>>
>> and navigated to this line. This seems to be it. The (setenv) function.
>> Can be used as from a modified packaging phase function (as you can see
>> in engineering.scm).
>>
>> Hope I helped. Good luck once again!
>>
>> W.
>>
>> P.S. Make sure you know some ’less’ shortcuts if you’re going to do
>>      things this way. It cad speed things up ^^
>>
>> – (sig_start)
>> website: <https://koszko.org/koszko.html>
>> PGP: <https://koszko.org/key.gpg>
>> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>>
>> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
>> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
>> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
>> – (sig_end)
>>
>>
>> On Wed, 16 Nov 2022 21:38:47 +0100
>> Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>>
>>> Hi,
>>>
>>> You’re both right, seems there is a flag to skip binary downloading and
>>> compile the V8 lib.
>>>
>>>  From the githubpage (<https://github.com/denoland/rusty_v8>) : “V8 is
>>> very large and takes a long time to compile. Many users will prefer to
>>> use a prebuilt version of V8. We publish static libs for every version
>>> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
>>>
>>> Binaries builds are turned on by default: |cargo build| will initiate a
>>> download from github to get the static lib. To disable this build using
>>> the |V8_FROM_SOURCE| environmental variable.
>>>
>>> When making changes to rusty_v8 itself, it should be tested by build
>>> from source. The CI always builds from source”
>>>
>>> So, my packaging friend :), what’s the best way to push an “export
>>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>>>
>>> Best,
>>>
>>> SR
>>>
>>> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :
>>> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:
>>> >> Hi,
>>> >>
>>> >> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
>>> >>
>>> >> I push the channel to reproduce the problem here :
>>> >>
>>> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
>>> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
>>> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
>>> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
>>> >>
>>> >> And the rust error :
>>> >>
>>> >> —
>>> >>
>>> >> error: failed to run custom build command for `v8 v0.49.0`
>>> >>
>>> >> Caused by:
>>> >>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>>> >>    — stdout
>>> >>    cargo:rerun-if-changed=.gn
>>> >>    cargo:rerun-if-changed=BUILD.gn
>>> >>    cargo:rerun-if-changed=src/binding.cc
>>> >>    cargo:rerun-if-env-changed=CCACHE
>>> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
>>> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
>>> >>    cargo:rerun-if-env-changed=DOCS_RS
>>> >>    cargo:rerun-if-env-changed=GN
>>> >>    cargo:rerun-if-env-changed=GN_ARGS
>>> >>    cargo:rerun-if-env-changed=HOST
>>> >>    cargo:rerun-if-env-changed=NINJA
>>> >>    cargo:rerun-if-env-changed=OUT_DIR
>>> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>>> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>>> >>    cargo:rerun-if-env-changed=SCCACHE
>>> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>>> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
>>> >>    cargo:rustc-link-lib=static=rusty_v8
>>> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>>> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>>> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>>> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>>> >>    Python downloader failed, trying with curl.
>>> > Looks like you need to patch rust-v8-0.49 to not try to download
>>> > librusty_v8_release… but instead you’ll have to build it from source
>>> > and let it know where to find it.
>>> >
>>> >>    — stderr
>>> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
>>> >> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
>>> >> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>>> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
>>> >> warning: build failed, waiting for other jobs to finish…
>>> >> error: build failed
>>> >> error: in phase ’build’: uncaught exception:
>>> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
>>> >> phase `build’ failed after 105.5 seconds
>>> >> command “cargo” “build” “–release” failed with status 101
>>> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
>>> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
>>> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
>>> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed
>>> >
>>
>>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 885 bytes --]

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 14898 bytes --]

Hello again

I am impressed with your determination :)

I see most packages in Guix that use `(method git-fetch)` also use
`(file-name (git-file-name name version))` in `(origin)`.

Note that this only affects the name under which the git checkout is
saved. Whether the source checkout directory under `/gnu/store` is
named `8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/`
or something else should not be relevant to the build.

Although I doubt I will be able to help with no knowledge of Rust, I'll
at least suggest that you attach the full rust-deno build logs here.
This will perhaps at least enable others to help (the time needed to
build it all does scare away!).

Btw, it seems awkward to be required to provide the test_util package
as a separate crate. I'd rather imagine Deno devs somehow using the
test_util sources already in the deno tree.

Have you tried fiddling around inside the build container? If not, you
may want to look at this manual node[1]. Perhaps after running some of
the build commands manually you'll get better ideas?

At the end, in the worst case, you could resort to disabling tests for
the package. Nobody likes this "solution" but sometimes it is the only
way to go ¯\_(ツ)_/¯

Good luck,
Wojtek

[1] https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #24: blessed Ludwik Pius Bartosik
Poznaj świętych krakowskich!  #24: błogosławiony Ludwik Pius Bartosik
https://pl.wikipedia.org/wiki/Ludwik_Pius_Bartosik
-- (sig_end)


On Wed, 14 Dec 2022 11:30:16 +0100
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Hi,
> 
> After two weeks of suffering and pain with this complex rust packaging, and thanks to people on the libera #guix chat, my “rust packaging adventure” is near ending… at least with deno, i see quarto after that…
> 
> Everything compile by parts, and i need a final help to merge things.
> 
> I only have a problem at `testing-phase', with a local rust package defined on Deno `/test_util' folder. This package is not published at all on crates.io and it’s needed at test-phase…
> 
> This nested crate package is not detected/compiled by actual `cargo-build-system', so i decide to package it myself , as `rust-deno-test-util-0.1.0'
> 
> I tested and this crate compile well, with two derivation :
> 
> • `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/'
> • `/gnu/store/zp5flzykz7y5n35kqrlryqkynvrvcw3z-rust-deno-test-util-0.1.0.drv'
> 
> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/'  contain the test_util-0.1.0.crate
> 
> So … i added this *.scm* to my *deno/deno-dep* list of package in the *rust-channel* needed by deno to compile :
> <https://git.sr.ht/~reyman/rust-channel/tree/543fee4cc3626ae27da5b41a7884cecb71b9dcf8/item/deno-dep/rust-deno-test-util-0-1-0.scm>
> 
> *My problem is simple?* i added this crate as a dependency of my main `rust-deno.scm' :
> • `#:use-module (deno-dep rust-deno-test-util-0-1-0)'
> • `#:cargo-development-inputs `((("rust-deno-test-util", rust-deno-test-util-0.1.0) ... )'
> 
> BUT BUT BUT … rust-deno-test-util is not found and not added to `/guix-vendor' during deno crate retrieval, so there is a problem somewhere during packaging retrieval from local `/gnu/store'. I found in the log that
> 
> `/gnu/store/8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/'  contain the sources and not a `tar.gz' like others crates. I suppose this is part of the problem, but i don’t know how to solve that.
> 
> See by yourself using :
> 
> guix time-machine -C channels.scm – build -f rust-deno.scm
> 
> that return :
> 
> error: no matching package named `deno_test_util` found
> 
> **Info to reproduce**
> 
> • All these package needed by Deno are defined into my-rust channel here : <https://git.sr.ht/~reyman/rust-channel>
> • The building and channel scm needed to build deno are here : <https://git.sr.ht/~reyman/build-deno-guix>
> • /Final Warning :/ Deno build (outside rust build) take at least 2 hours on my machine, rusty-v8 is huge and take itself ~30 to 45 minutes.
> 
> Any *final* help appreciated !
> 
> Best ,
> Sébastien Rey-Coyrehourcq
> 
> 
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:
> 
> >
> > Hi,
> >
> > Thanks a lot, that helps me to make one more step :)
> >
> > I set :
> >
> > ┌────
> > │     (arguments
> > │         `(#:phases
> > │            (modify-phases %standard-phases
> > │          (add-before ’configure ’set-source
> > │            (lambda _
> > │              (setenv “V8_FROM_SOURCE” “1”)
> > │              (setenv “RUST_BACKTRACE” “1”)
> > │              (setenv “CLANG_BASE_PATH” (getenv “CMAKE_PREFIX_PATH”))
> > │              #t)))
> > └────
> >
> > I also try C_INCLUDE_PATH
> >
> > and native input :
> >
> > ┌────
> > │ 	(native-inputs (list ninja gn clang-toolchain ccache clang))
> > └────
> >
> > I have now another problem during compilation of v8, i don’t understand why “clang” path is not well recognized by the buildscript, test is defined here :
> >
> > <https://github.com/denoland/rusty_v8/blob/main/build.rs#L517>
> >
> > The backtrace :
> >
> > error: failed to run custom build command for `v8 v0.49.0`
> >
> > Caused by:
> >   process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
> >   — stdout
> >   cargo:rerun-if-changed=.gn
> >   cargo:rerun-if-changed=BUILD.gn
> >   cargo:rerun-if-changed=src/binding.cc
> >   cargo:rerun-if-env-changed=CCACHE
> >   cargo:rerun-if-env-changed=CLANG_BASE_PATH
> >   cargo:rerun-if-env-changed=DENO_TRYBUILD
> >   cargo:rerun-if-env-changed=DOCS_RS
> >   cargo:rerun-if-env-changed=GN
> >   cargo:rerun-if-env-changed=GN_ARGS
> >   cargo:rerun-if-env-changed=HOST
> >   cargo:rerun-if-env-changed=NINJA
> >   cargo:rerun-if-env-changed=OUT_DIR
> >   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
> >   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
> >   cargo:rerun-if-env-changed=SCCACHE
> >   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
> >   cargo:rerun-if-env-changed=V8_FROM_SOURCE
> >   cargo:rustc-link-lib=static=rusty_v8
> >   using Chromiums clang
> >   clang_base_path /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/clang
> >
> > — stderr
> > thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:537:6
> > stack backtrace:
> >    0: rust_begin_unwind
> >    1: core::panicking::panic_fmt
> >    2: core::result::unwrap_failed
> >    3: core::result::Result<T,E>::unwrap
> >    4: build_script_build::clang_download
> >    5: build_script_build::build_v8
> >    6: build_script_build::main
> >    7: core::ops::function::FnOnce::call_once
> > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
> >
> > Best,
> >
> >
> > Wojtek Kosior <koszko@koszko.org> writes:
> >  
> >>> Hi,
> >>>
> >>> You’re both right, seems there is a flag to skip binary downloading and
> >>> compile the V8 lib.
> >>>
> >>> […]  
> >>
> >> Good to see you found it :)
> >>  
> >>> So, my packaging friend :), what’s the best way to push an “export
> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
> >>>
> >>> Best,
> >>>
> >>> SR  
> >>
> >> When I first read your question, I did not know the exact function. But
> >> I knew where to look. So I thought I’d better share my way of learning
> >> rather than just the solution ;)
> >>
> >> I started with
> >>
> >>     grep -R ’export’ ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less
> >>
> >> That showed a lot of results. I noticed a line like this
> >>  
> >>> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:             (setenv “HOME” (getcwd)) ;; cmake needs this to export modules  
> >>
> >> Thought it might be the thing I was looking for, so I did
> >>
> >>     less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm
> >>
> >> and navigated to this line. This seems to be it. The (setenv) function.
> >> Can be used as from a modified packaging phase function (as you can see
> >> in engineering.scm).
> >>
> >> Hope I helped. Good luck once again!
> >>
> >> W.
> >>
> >> P.S. Make sure you know some ’less’ shortcuts if you’re going to do
> >>      things this way. It cad speed things up ^^
> >>
> >> – (sig_start)
> >> website: <https://koszko.org/koszko.html>
> >> PGP: <https://koszko.org/key.gpg>
> >> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >>
> >> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
> >> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
> >> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
> >> – (sig_end)
> >>
> >>
> >> On Wed, 16 Nov 2022 21:38:47 +0100
> >> Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> >>  
> >>> Hi,
> >>>
> >>> You’re both right, seems there is a flag to skip binary downloading and
> >>> compile the V8 lib.
> >>>
> >>>  From the githubpage (<https://github.com/denoland/rusty_v8>) : “V8 is
> >>> very large and takes a long time to compile. Many users will prefer to
> >>> use a prebuilt version of V8. We publish static libs for every version
> >>> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
> >>>
> >>> Binaries builds are turned on by default: |cargo build| will initiate a
> >>> download from github to get the static lib. To disable this build using
> >>> the |V8_FROM_SOURCE| environmental variable.
> >>>
> >>> When making changes to rusty_v8 itself, it should be tested by build
> >>> from source. The CI always builds from source”
> >>>
> >>> So, my packaging friend :), what’s the best way to push an “export
> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
> >>>
> >>> Best,
> >>>
> >>> SR
> >>>
> >>> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :  
> >>> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:  
> >>> >> Hi,
> >>> >>
> >>> >> After some day of packaging rust crate, i progress and deno start to compile … but after 1min i have this error when cargo start compiling *rust-v8-0.49* . Any rust + guix help appreciated.
> >>> >>
> >>> >> I push the channel to reproduce the problem here :
> >>> >>
> >>> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
> >>> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
> >>> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
> >>> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
> >>> >>
> >>> >> And the rust error :
> >>> >>
> >>> >> —
> >>> >>
> >>> >> error: failed to run custom build command for `v8 v0.49.0`
> >>> >>
> >>> >> Caused by:
> >>> >>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
> >>> >>    — stdout
> >>> >>    cargo:rerun-if-changed=.gn
> >>> >>    cargo:rerun-if-changed=BUILD.gn
> >>> >>    cargo:rerun-if-changed=src/binding.cc
> >>> >>    cargo:rerun-if-env-changed=CCACHE
> >>> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
> >>> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
> >>> >>    cargo:rerun-if-env-changed=DOCS_RS
> >>> >>    cargo:rerun-if-env-changed=GN
> >>> >>    cargo:rerun-if-env-changed=GN_ARGS
> >>> >>    cargo:rerun-if-env-changed=HOST
> >>> >>    cargo:rerun-if-env-changed=NINJA
> >>> >>    cargo:rerun-if-env-changed=OUT_DIR
> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
> >>> >>    cargo:rerun-if-env-changed=SCCACHE
> >>> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
> >>> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
> >>> >>    cargo:rustc-link-lib=static=rusty_v8
> >>> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
> >>> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
> >>> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
> >>> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
> >>> >>    Python downloader failed, trying with curl.  
> >>> > Looks like you need to patch rust-v8-0.49 to not try to download
> >>> > librusty_v8_release… but instead you’ll have to build it from source
> >>> > and let it know where to find it.
> >>> >  
> >>> >>    — stderr
> >>> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
> >>> >> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
> >>> >> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
> >>> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> >>> >> warning: build failed, waiting for other jobs to finish…
> >>> >> error: build failed
> >>> >> error: in phase ’build’: uncaught exception:
> >>> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
> >>> >> phase `build’ failed after 105.5 seconds
> >>> >> command “cargo” “build” “–release” failed with status 101
> >>> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
> >>> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
> >>> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
> >>> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed  
> >>> >  
> >>
> >>  
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 17594 bytes --]

Wojtek Kosior <koszko@koszko.org> writes:


> Hello again
>
> I am impressed with your determination :)
>

thx :D

> I see most packages in Guix that use `(method git-fetch)` also use
> `(file-name (git-file-name name version))` in `(origin)`.
>
> Note that this only affects the name under which the git checkout is
> saved. Whether the source checkout directory under `/gnu/store` is
> named `8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/`
> or something else should not be relevant to the build.
>

Yes, you’re right i correct this thing, but this is weird in all case, here i clone all deno repository (at tag v1.25.2), and this is renamed as `deno-test-util-checkout-0-1-0' because i’m only interested by this folder

<https://git.sr.ht/~reyman/rust-channel/commit/00e9ef93bbe5a853b8a196305b6d86451c036156>

I found only one crate that use this method `git-fetch' in the list :
<https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>

So i suppose this is possible to reuse as a dependency in another build…

This is an intuition but i think i have a problem of ordering in my way to do things :

When i read the `cargo-build-system' sources here ( <https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm#L76> ) i see that the build input wait for an /gnu/store link that contain a `.crate' or the equivalent as `tar.gz'

Or in my case, the /gnu/store link called by cargo contain only sources, because the `deno-util' need to be built before creating .crate into the gnu/store. Perhaps i could cheating the system by providing myself a `gnu/store/xxxx.tar.gz' that contain this sources.

Inside my `rust-deno-test-util-1-0-0.scm` file i could  `(invoke tar ...)' command to generate a tar.gz at the root of the this folder. Do you think that could work ?

Hum, not sure … the real problem is the fact that guix don’t build the derivation completely? (creating and storing a .crate for deno-test-util-0-1-0 into /gnu/store) when i run build of main rust-deno.scm … only the source are present, and not the package resulting from the build of this derivation.

Another way is to first compile deno-test-util.scm, that install the corresponding crate into /gnu/store, and after that i give this local path to the inputs of my main rust-deno.scm . But i don’t know how to give this path to my cargo build system input . How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?

> Although I doubt I will be able to help with no knowledge of Rust, I’ll
> at least suggest that you attach the full rust-deno build logs here.
> This will perhaps at least enable others to help (the time needed to
> build it all does scare away!).
>
> Btw, it seems awkward to be required to provide the test_util package
> as a separate crate. I’d rather imagine Deno devs somehow using the
> test_util sources already in the deno tree.
>

Yeah, but now it’s packaged and the package compile, i try one more time like that :D

> Have you tried fiddling around inside the build container? If not, you
> may want to look at this manual node[1]. Perhaps after running some of
> the build commands manually you’ll get better ideas?

Thanks i will look on that
>
> At the end, in the worst case, you could resort to disabling tests for
> the package. Nobody likes this “solution” but sometimes it is the only
> way to go ¯\_(ツ)_/¯

Ahah right, i probably do that if i want to finish in 2022 :D

Best,
Sébastien Rey-Coyrehourcq

>
> Good luck,
> Wojtek
>
> [1] <https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html>
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #24: blessed Ludwik Pius Bartosik
> Poznaj świętych krakowskich!  #24: błogosławiony Ludwik Pius Bartosik
> <https://pl.wikipedia.org/wiki/Ludwik_Pius_Bartosik>
> – (sig_end)
>
>
> On Wed, 14 Dec 2022 11:30:16 +0100
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Hi,
>>
>> After two weeks of suffering and pain with this complex rust packaging, and
>> thanks to people on the libera #guix chat, my “rust packaging adventure” is
>> near ending… at least with deno, i see quarto after that…
>>
>> Everything compile by parts, and i need a final help to merge things.
>>
>> I only have a problem at `testing-phase’, with a local rust package defined on Deno `/test_util’ folder. This package is not published at all on crates.io and it’s needed at test-phase…
>>
>> This nested crate package is not detected/compiled by actual `cargo-build-system’, so i decide to package it myself , as `rust-deno-test-util-0.1.0’
>>
>> I tested and this crate compile well, with two derivation :
>>
>> • `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/’
>> • `/gnu/store/zp5flzykz7y5n35kqrlryqkynvrvcw3z-rust-deno-test-util-0.1.0.drv’
>>
>> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/’  contain the test_util-0.1.0.crate
>>
>> So … i added this *.scm* to my *deno/deno-dep* list of package in the *rust-channel* needed by deno to compile :
>> <https://git.sr.ht/~reyman/rust-channel/tree/543fee4cc3626ae27da5b41a7884cecb71b9dcf8/item/deno-dep/rust-deno-test-util-0-1-0.scm>
>>
>> *My problem is simple?* i added this crate as a dependency of my main `rust-deno.scm’ :
>> • `#:use-module (deno-dep rust-deno-test-util-0-1-0)’
>> • `#:cargo-development-inputs `(((“rust-deno-test-util”, rust-deno-test-util-0.1.0) … )’
>>
>> BUT BUT BUT … rust-deno-test-util is not found and not added to `/guix-vendor’
>> during deno crate retrieval, so there is a problem somewhere during packaging
>> retrieval from local `/gnu/store’. I found in the log that
>>
>> `/gnu/store/8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/’
>> contain the sources and not a `tar.gz’ like others crates. I suppose this is
>> part of the problem, but i don’t know how to solve that.
>>
>> See by yourself using :
>>
>> guix time-machine -C channels.scm – build -f rust-deno.scm
>>
>> that return :
>>
>> error: no matching package named `deno_test_util` found
>>
>> **Info to reproduce**
>>
>> • All these package needed by Deno are defined into my-rust channel here : <https://git.sr.ht/~reyman/rust-channel>
>> • The building and channel scm needed to build deno are here : <https://git.sr.ht/~reyman/build-deno-guix>
>> • /Final Warning :/ Deno build (outside rust build) take at least 2 hours on my machine, rusty-v8 is huge and take itself ~30 to 45 minutes.
>>
>> Any *final* help appreciated !
>>
>> Best ,
>> Sébastien Rey-Coyrehourcq
>>
>>
>> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:
>>
>> >
>> > Hi,
>> >
>> > Thanks a lot, that helps me to make one more step :)
>> >
>> > I set :
>> >
>> > ┌────
>> > │     (arguments
>> > │         `(#:phases
>> > │            (modify-phases %standard-phases
>> > │          (add-before ’configure ’set-source
>> > │            (lambda _
>> > │              (setenv “V8_FROM_SOURCE” “1”)
>> > │              (setenv “RUST_BACKTRACE” “1”)
>> > │              (setenv “CLANG_BASE_PATH” (getenv “CMAKE_PREFIX_PATH”))
>> > │              #t)))
>> > └────
>> >
>> > I also try C_INCLUDE_PATH
>> >
>> > and native input :
>> >
>> > ┌────
>> > │ 	(native-inputs (list ninja gn clang-toolchain ccache clang))
>> > └────
>> >
>> > I have now another problem during compilation of v8, i don’t understand why “clang” path is not well recognized by the buildscript, test is defined here :
>> >
>> > <https://github.com/denoland/rusty_v8/blob/main/build.rs#L517>
>> >
>> > The backtrace :
>> >
>> > error: failed to run custom build command for `v8 v0.49.0`
>> >
>> > Caused by:
>> >   process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>> >   — stdout
>> >   cargo:rerun-if-changed=.gn
>> >   cargo:rerun-if-changed=BUILD.gn
>> >   cargo:rerun-if-changed=src/binding.cc
>> >   cargo:rerun-if-env-changed=CCACHE
>> >   cargo:rerun-if-env-changed=CLANG_BASE_PATH
>> >   cargo:rerun-if-env-changed=DENO_TRYBUILD
>> >   cargo:rerun-if-env-changed=DOCS_RS
>> >   cargo:rerun-if-env-changed=GN
>> >   cargo:rerun-if-env-changed=GN_ARGS
>> >   cargo:rerun-if-env-changed=HOST
>> >   cargo:rerun-if-env-changed=NINJA
>> >   cargo:rerun-if-env-changed=OUT_DIR
>> >   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>> >   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>> >   cargo:rerun-if-env-changed=SCCACHE
>> >   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>> >   cargo:rerun-if-env-changed=V8_FROM_SOURCE
>> >   cargo:rustc-link-lib=static=rusty_v8
>> >   using Chromiums clang
>> >   clang_base_path /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/clang
>> >
>> > — stderr
>> > thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:537:6
>> > stack backtrace:
>> >    0: rust_begin_unwind
>> >    1: core::panicking::panic_fmt
>> >    2: core::result::unwrap_failed
>> >    3: core::result::Result<T,E>::unwrap
>> >    4: build_script_build::clang_download
>> >    5: build_script_build::build_v8
>> >    6: build_script_build::main
>> >    7: core::ops::function::FnOnce::call_once
>> > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
>> >
>> > Best,
>> >
>> >
>> > Wojtek Kosior <koszko@koszko.org> writes:
>> >
>> >>> Hi,
>> >>>
>> >>> You’re both right, seems there is a flag to skip binary downloading and
>> >>> compile the V8 lib.
>> >>>
>> >>> […]
>> >>
>> >> Good to see you found it :)
>> >>
>> >>> So, my packaging friend :), what’s the best way to push an “export
>> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>> >>>
>> >>> Best,
>> >>>
>> >>> SR
>> >>
>> >> When I first read your question, I did not know the exact function. But
>> >> I knew where to look. So I thought I’d better share my way of learning
>> >> rather than just the solution ;)
>> >>
>> >> I started with
>> >>
>> >>     grep -R ’export’ ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less
>> >>
>> >> That showed a lot of results. I noticed a line like this
>> >>
>> >>> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:             (setenv “HOME” (getcwd)) ;; cmake needs this to export modules
>> >>
>> >> Thought it might be the thing I was looking for, so I did
>> >>
>> >>     less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm
>> >>
>> >> and navigated to this line. This seems to be it. The (setenv) function.
>> >> Can be used as from a modified packaging phase function (as you can see
>> >> in engineering.scm).
>> >>
>> >> Hope I helped. Good luck once again!
>> >>
>> >> W.
>> >>
>> >> P.S. Make sure you know some ’less’ shortcuts if you’re going to do
>> >>      things this way. It cad speed things up ^^
>> >>
>> >> – (sig_start)
>> >> website: <https://koszko.org/koszko.html>
>> >> PGP: <https://koszko.org/key.gpg>
>> >> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >>
>> >> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
>> >> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
>> >> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
>> >> – (sig_end)
>> >>
>> >>
>> >> On Wed, 16 Nov 2022 21:38:47 +0100
>> >> Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> You’re both right, seems there is a flag to skip binary downloading and
>> >>> compile the V8 lib.
>> >>>
>> >>>  From the githubpage (<https://github.com/denoland/rusty_v8>) : “V8 is
>> >>> very large and takes a long time to compile. Many users will prefer to
>> >>> use a prebuilt version of V8. We publish static libs for every version
>> >>> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
>> >>>
>> >>> Binaries builds are turned on by default: |cargo build| will initiate a
>> >>> download from github to get the static lib. To disable this build using
>> >>> the |V8_FROM_SOURCE| environmental variable.
>> >>>
>> >>> When making changes to rusty_v8 itself, it should be tested by build
>> >>> from source. The CI always builds from source”
>> >>>
>> >>> So, my packaging friend :), what’s the best way to push an “export
>> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>> >>>
>> >>> Best,
>> >>>
>> >>> SR
>> >>>
>> >>> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :
>> >>> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> After some day of packaging rust crate, i progress and deno start to
>> >>> >> compile … but after 1min i have this error when cargo start compiling
>> >>> >> *rust-v8-0.49* . Any rust + guix help appreciated.
>> >>> >>
>> >>> >> I push the channel to reproduce the problem here :
>> >>> >>
>> >>> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
>> >>> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
>> >>> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
>> >>> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
>> >>> >>
>> >>> >> And the rust error :
>> >>> >>
>> >>> >> —
>> >>> >>
>> >>> >> error: failed to run custom build command for `v8 v0.49.0`
>> >>> >>
>> >>> >> Caused by:
>> >>> >>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
>> >>> >>    — stdout
>> >>> >>    cargo:rerun-if-changed=.gn
>> >>> >>    cargo:rerun-if-changed=BUILD.gn
>> >>> >>    cargo:rerun-if-changed=src/binding.cc
>> >>> >>    cargo:rerun-if-env-changed=CCACHE
>> >>> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
>> >>> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
>> >>> >>    cargo:rerun-if-env-changed=DOCS_RS
>> >>> >>    cargo:rerun-if-env-changed=GN
>> >>> >>    cargo:rerun-if-env-changed=GN_ARGS
>> >>> >>    cargo:rerun-if-env-changed=HOST
>> >>> >>    cargo:rerun-if-env-changed=NINJA
>> >>> >>    cargo:rerun-if-env-changed=OUT_DIR
>> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>> >>> >>    cargo:rerun-if-env-changed=SCCACHE
>> >>> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>> >>> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
>> >>> >>    cargo:rustc-link-lib=static=rusty_v8
>> >>> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>> >>> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>> >>> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>> >>> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>> >>> >>    Python downloader failed, trying with curl.
>> >>> > Looks like you need to patch rust-v8-0.49 to not try to download
>> >>> > librusty_v8_release… but instead you’ll have to build it from source
>> >>> > and let it know where to find it.
>> >>> >
>> >>> >>    — stderr
>> >>> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
>> >>> >> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
>> >>> >> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>> >>> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
>> >>> >> warning: build failed, waiting for other jobs to finish…
>> >>> >> error: build failed
>> >>> >> error: in phase ’build’: uncaught exception:
>> >>> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
>> >>> >> phase `build’ failed after 105.5 seconds
>> >>> >> command “cargo” “build” “–release” failed with status 101
>> >>> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
>> >>> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
>> >>> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
>> >>> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed
>> >>> >
>> >>
>> >>
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 23675 bytes --]

> Yes, you’re right i correct this thing, but this is weird in all case, here i clone all deno repository (at tag v1.25.2), and this is renamed as `deno-test-util-checkout-0-1-0' because i’m only interested by this folder
> 
> <https://git.sr.ht/~reyman/rust-channel/commit/00e9ef93bbe5a853b8a196305b6d86451c036156>

Ah, I see why you wanted a name like this. Well, since the sources are
the same as those of rust-deno, perhaps it would make sense to use the
same origin as in rust-deno recipe?

But don't worry about this now. Your build of rust-deno-test-util
evidently worked so cleaning up origin definitions can wait until
everything else works :)

> I found only one crate that use this method `git-fetch' in the list :
> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>

There are plenty in other package definition files, e.g. in
gnu/packages/python-xyz.scm. It seems Rust is just that special case
where git checkout is rarely needed.

> So i suppose this is possible to reuse as a dependency in another build…
> 
> This is an intuition but i think i have a problem of ordering in my way to do things :
> 
> When i read the `cargo-build-system' sources here ( <https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm#L76> ) i see that the build input wait for an /gnu/store link that contain a `.crate' or the equivalent as `tar.gz'
> 
> Or in my case, the /gnu/store link called by cargo contain only sources, because the `deno-util' need to be built before creating .crate into the gnu/store. Perhaps i could cheating the system by providing myself a `gnu/store/xxxx.tar.gz' that contain this sources.
> 
> Inside my `rust-deno-test-util-1-0-0.scm` file i could  `(invoke tar ...)' command to generate a tar.gz at the root of the this folder. Do you think that could work ?
> 
> Hum, not sure … the real problem is the fact that guix don’t build the derivation completely? (creating and storing a .crate for deno-test-util-0-1-0 into /gnu/store) when i run build of main rust-deno.scm … only the source are present, and not the package resulting from the build of this derivation.
> 
> Another way is to first compile deno-test-util.scm, that install the corresponding crate into /gnu/store, and after that i give this local path to the inputs of my main rust-deno.scm . But i don’t know how to give this path to my cargo build system input .

I'm getting a bit lost in trying to figure out what you think right
now. The
`/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/`
was a proper build of your `rust-deno-test-util` package and it
contains a proper crate under `share/cargo/registry/`. Code in
`cargo-build-system.scm` looks for crates in subdirectory
`share/cargo/registry/` of every rust input package — all seems correct
under the assumption that we want test_util to be supplied to deno
build as a separate Guix package.

It's perhaps possible to achieve success with this assumption (I don't
know) but I wanted to instead suggest not creating a separate Guix
package nor derivation for test_util. That's what I meant when I wrote
"it seems awkward to be required to provide the test_util package as a
separate crate". Sorry if I accidently mislead you with this.

Earlier you wrote

> This nested crate package is not detected/compiled by actual
> `cargo-build-system’, so i decide to package it myself , as
> `rust-deno-test-util-0.1.0’

What seems to be the most straightforward and promising way is to
(somehow?) fix the build system to detect the nested package. I know,
it's easy to say — and you surely made extensive attempts before
falling back to creating an extra definition for rust-deno-test-util.
Hopefully, inspection of the build container will help shed some light
on this.

Also, the git-fetch issues will become nonexistent if you manage to do
it this way :)

Since your rust-deno recipe uses `(method url-fetch)` with
`(crate-uri)`, I'm starting to wonder if the tarball that's being used
in this case contains exactly the same files as the git checkout. I
earlier assumed that it does when I suggested reusing the origin in
your rust-deno-test-util recipe. But perhaps it doesn't? I could
imagine deno devs omitting e.g. `test_util/` from the source tarball
they upload to the crates repo.

> How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?

You don't :)

That's the point of a functional package manager - there's never need
to *explicitly* reference files in the store. They are always referenced
indirectly through packages, derivations, plain-file's, gexps, etc. And
they get created or reused automatically.

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #25: blessed Maksymilian Binkiewicz
Poznaj świętych krakowskich!  #25: błogosławiony Maksymilian Binkiewicz
https://pl.wikipedia.org/wiki/Maksymilian_Binkiewicz
-- (sig_end)


On Wed, 14 Dec 2022 17:16:45 +0100
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Wojtek Kosior <koszko@koszko.org> writes:
> 
> 
> > Hello again
> >
> > I am impressed with your determination :)
> >  
> 
> thx :D
> 
> > I see most packages in Guix that use `(method git-fetch)` also use
> > `(file-name (git-file-name name version))` in `(origin)`.
> >
> > Note that this only affects the name under which the git checkout is
> > saved. Whether the source checkout directory under `/gnu/store` is
> > named `8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/`
> > or something else should not be relevant to the build.
> >  
> 
> Yes, you’re right i correct this thing, but this is weird in all case, here i clone all deno repository (at tag v1.25.2), and this is renamed as `deno-test-util-checkout-0-1-0' because i’m only interested by this folder
> 
> <https://git.sr.ht/~reyman/rust-channel/commit/00e9ef93bbe5a853b8a196305b6d86451c036156>
> 
> I found only one crate that use this method `git-fetch' in the list :
> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>
> 
> So i suppose this is possible to reuse as a dependency in another build…
> 
> This is an intuition but i think i have a problem of ordering in my way to do things :
> 
> When i read the `cargo-build-system' sources here ( <https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm#L76> ) i see that the build input wait for an /gnu/store link that contain a `.crate' or the equivalent as `tar.gz'
> 
> Or in my case, the /gnu/store link called by cargo contain only sources, because the `deno-util' need to be built before creating .crate into the gnu/store. Perhaps i could cheating the system by providing myself a `gnu/store/xxxx.tar.gz' that contain this sources.
> 
> Inside my `rust-deno-test-util-1-0-0.scm` file i could  `(invoke tar ...)' command to generate a tar.gz at the root of the this folder. Do you think that could work ?
> 
> Hum, not sure … the real problem is the fact that guix don’t build the derivation completely? (creating and storing a .crate for deno-test-util-0-1-0 into /gnu/store) when i run build of main rust-deno.scm … only the source are present, and not the package resulting from the build of this derivation.
> 
> Another way is to first compile deno-test-util.scm, that install the corresponding crate into /gnu/store, and after that i give this local path to the inputs of my main rust-deno.scm . But i don’t know how to give this path to my cargo build system input . How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?
> 
> > Although I doubt I will be able to help with no knowledge of Rust, I’ll
> > at least suggest that you attach the full rust-deno build logs here.
> > This will perhaps at least enable others to help (the time needed to
> > build it all does scare away!).
> >
> > Btw, it seems awkward to be required to provide the test_util package
> > as a separate crate. I’d rather imagine Deno devs somehow using the
> > test_util sources already in the deno tree.
> >  
> 
> Yeah, but now it’s packaged and the package compile, i try one more time like that :D
> 
> > Have you tried fiddling around inside the build container? If not, you
> > may want to look at this manual node[1]. Perhaps after running some of
> > the build commands manually you’ll get better ideas?  
> 
> Thanks i will look on that
> >
> > At the end, in the worst case, you could resort to disabling tests for
> > the package. Nobody likes this “solution” but sometimes it is the only
> > way to go ¯\_(ツ)_/¯  
> 
> Ahah right, i probably do that if i want to finish in 2022 :D
> 
> Best,
> Sébastien Rey-Coyrehourcq
> 
> >
> > Good luck,
> > Wojtek
> >
> > [1] <https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html>
> >
> > – (sig_start)
> > website: <https://koszko.org/koszko.html>
> > PGP: <https://koszko.org/key.gpg>
> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >
> > Meet Kraków saints!           #24: blessed Ludwik Pius Bartosik
> > Poznaj świętych krakowskich!  #24: błogosławiony Ludwik Pius Bartosik
> > <https://pl.wikipedia.org/wiki/Ludwik_Pius_Bartosik>
> > – (sig_end)
> >
> >
> > On Wed, 14 Dec 2022 11:30:16 +0100
> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> >  
> >> Hi,
> >>
> >> After two weeks of suffering and pain with this complex rust packaging, and
> >> thanks to people on the libera #guix chat, my “rust packaging adventure” is
> >> near ending… at least with deno, i see quarto after that…
> >>
> >> Everything compile by parts, and i need a final help to merge things.
> >>
> >> I only have a problem at `testing-phase’, with a local rust package defined on Deno `/test_util’ folder. This package is not published at all on crates.io and it’s needed at test-phase…
> >>
> >> This nested crate package is not detected/compiled by actual `cargo-build-system’, so i decide to package it myself , as `rust-deno-test-util-0.1.0’
> >>
> >> I tested and this crate compile well, with two derivation :
> >>
> >> • `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/’
> >> • `/gnu/store/zp5flzykz7y5n35kqrlryqkynvrvcw3z-rust-deno-test-util-0.1.0.drv’
> >>
> >> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/’  contain the test_util-0.1.0.crate
> >>
> >> So … i added this *.scm* to my *deno/deno-dep* list of package in the *rust-channel* needed by deno to compile :
> >> <https://git.sr.ht/~reyman/rust-channel/tree/543fee4cc3626ae27da5b41a7884cecb71b9dcf8/item/deno-dep/rust-deno-test-util-0-1-0.scm>
> >>
> >> *My problem is simple?* i added this crate as a dependency of my main `rust-deno.scm’ :
> >> • `#:use-module (deno-dep rust-deno-test-util-0-1-0)’
> >> • `#:cargo-development-inputs `(((“rust-deno-test-util”, rust-deno-test-util-0.1.0) … )’
> >>
> >> BUT BUT BUT … rust-deno-test-util is not found and not added to `/guix-vendor’
> >> during deno crate retrieval, so there is a problem somewhere during packaging
> >> retrieval from local `/gnu/store’. I found in the log that
> >>
> >> `/gnu/store/8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/’
> >> contain the sources and not a `tar.gz’ like others crates. I suppose this is
> >> part of the problem, but i don’t know how to solve that.
> >>
> >> See by yourself using :
> >>
> >> guix time-machine -C channels.scm – build -f rust-deno.scm
> >>
> >> that return :
> >>
> >> error: no matching package named `deno_test_util` found
> >>
> >> **Info to reproduce**
> >>
> >> • All these package needed by Deno are defined into my-rust channel here : <https://git.sr.ht/~reyman/rust-channel>
> >> • The building and channel scm needed to build deno are here : <https://git.sr.ht/~reyman/build-deno-guix>
> >> • /Final Warning :/ Deno build (outside rust build) take at least 2 hours on my machine, rusty-v8 is huge and take itself ~30 to 45 minutes.
> >>
> >> Any *final* help appreciated !
> >>
> >> Best ,
> >> Sébastien Rey-Coyrehourcq
> >>
> >>
> >> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:
> >>  
> >> >
> >> > Hi,
> >> >
> >> > Thanks a lot, that helps me to make one more step :)
> >> >
> >> > I set :
> >> >
> >> > ┌────
> >> > │     (arguments
> >> > │         `(#:phases
> >> > │            (modify-phases %standard-phases
> >> > │          (add-before ’configure ’set-source
> >> > │            (lambda _
> >> > │              (setenv “V8_FROM_SOURCE” “1”)
> >> > │              (setenv “RUST_BACKTRACE” “1”)
> >> > │              (setenv “CLANG_BASE_PATH” (getenv “CMAKE_PREFIX_PATH”))
> >> > │              #t)))
> >> > └────
> >> >
> >> > I also try C_INCLUDE_PATH
> >> >
> >> > and native input :
> >> >
> >> > ┌────
> >> > │ 	(native-inputs (list ninja gn clang-toolchain ccache clang))
> >> > └────
> >> >
> >> > I have now another problem during compilation of v8, i don’t understand why “clang” path is not well recognized by the buildscript, test is defined here :
> >> >
> >> > <https://github.com/denoland/rusty_v8/blob/main/build.rs#L517>
> >> >
> >> > The backtrace :
> >> >
> >> > error: failed to run custom build command for `v8 v0.49.0`
> >> >
> >> > Caused by:
> >> >   process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
> >> >   — stdout
> >> >   cargo:rerun-if-changed=.gn
> >> >   cargo:rerun-if-changed=BUILD.gn
> >> >   cargo:rerun-if-changed=src/binding.cc
> >> >   cargo:rerun-if-env-changed=CCACHE
> >> >   cargo:rerun-if-env-changed=CLANG_BASE_PATH
> >> >   cargo:rerun-if-env-changed=DENO_TRYBUILD
> >> >   cargo:rerun-if-env-changed=DOCS_RS
> >> >   cargo:rerun-if-env-changed=GN
> >> >   cargo:rerun-if-env-changed=GN_ARGS
> >> >   cargo:rerun-if-env-changed=HOST
> >> >   cargo:rerun-if-env-changed=NINJA
> >> >   cargo:rerun-if-env-changed=OUT_DIR
> >> >   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
> >> >   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
> >> >   cargo:rerun-if-env-changed=SCCACHE
> >> >   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
> >> >   cargo:rerun-if-env-changed=V8_FROM_SOURCE
> >> >   cargo:rustc-link-lib=static=rusty_v8
> >> >   using Chromiums clang
> >> >   clang_base_path /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/clang
> >> >
> >> > — stderr
> >> > thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:537:6
> >> > stack backtrace:
> >> >    0: rust_begin_unwind
> >> >    1: core::panicking::panic_fmt
> >> >    2: core::result::unwrap_failed
> >> >    3: core::result::Result<T,E>::unwrap
> >> >    4: build_script_build::clang_download
> >> >    5: build_script_build::build_v8
> >> >    6: build_script_build::main
> >> >    7: core::ops::function::FnOnce::call_once
> >> > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
> >> >
> >> > Best,
> >> >
> >> >
> >> > Wojtek Kosior <koszko@koszko.org> writes:
> >> >  
> >> >>> Hi,
> >> >>>
> >> >>> You’re both right, seems there is a flag to skip binary downloading and
> >> >>> compile the V8 lib.
> >> >>>
> >> >>> […]  
> >> >>
> >> >> Good to see you found it :)
> >> >>  
> >> >>> So, my packaging friend :), what’s the best way to push an “export
> >> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
> >> >>>
> >> >>> Best,
> >> >>>
> >> >>> SR  
> >> >>
> >> >> When I first read your question, I did not know the exact function. But
> >> >> I knew where to look. So I thought I’d better share my way of learning
> >> >> rather than just the solution ;)
> >> >>
> >> >> I started with
> >> >>
> >> >>     grep -R ’export’ ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less
> >> >>
> >> >> That showed a lot of results. I noticed a line like this
> >> >>  
> >> >>> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:             (setenv “HOME” (getcwd)) ;; cmake needs this to export modules  
> >> >>
> >> >> Thought it might be the thing I was looking for, so I did
> >> >>
> >> >>     less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm
> >> >>
> >> >> and navigated to this line. This seems to be it. The (setenv) function.
> >> >> Can be used as from a modified packaging phase function (as you can see
> >> >> in engineering.scm).
> >> >>
> >> >> Hope I helped. Good luck once again!
> >> >>
> >> >> W.
> >> >>
> >> >> P.S. Make sure you know some ’less’ shortcuts if you’re going to do
> >> >>      things this way. It cad speed things up ^^
> >> >>
> >> >> – (sig_start)
> >> >> website: <https://koszko.org/koszko.html>
> >> >> PGP: <https://koszko.org/key.gpg>
> >> >> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> >> >>
> >> >> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
> >> >> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
> >> >> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
> >> >> – (sig_end)
> >> >>
> >> >>
> >> >> On Wed, 16 Nov 2022 21:38:47 +0100
> >> >> Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
> >> >>  
> >> >>> Hi,
> >> >>>
> >> >>> You’re both right, seems there is a flag to skip binary downloading and
> >> >>> compile the V8 lib.
> >> >>>
> >> >>>  From the githubpage (<https://github.com/denoland/rusty_v8>) : “V8 is
> >> >>> very large and takes a long time to compile. Many users will prefer to
> >> >>> use a prebuilt version of V8. We publish static libs for every version
> >> >>> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
> >> >>>
> >> >>> Binaries builds are turned on by default: |cargo build| will initiate a
> >> >>> download from github to get the static lib. To disable this build using
> >> >>> the |V8_FROM_SOURCE| environmental variable.
> >> >>>
> >> >>> When making changes to rusty_v8 itself, it should be tested by build
> >> >>> from source. The CI always builds from source”
> >> >>>
> >> >>> So, my packaging friend :), what’s the best way to push an “export
> >> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
> >> >>>
> >> >>> Best,
> >> >>>
> >> >>> SR
> >> >>>
> >> >>> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :  
> >> >>> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:  
> >> >>> >> Hi,
> >> >>> >>
> >> >>> >> After some day of packaging rust crate, i progress and deno start to
> >> >>> >> compile … but after 1min i have this error when cargo start compiling
> >> >>> >> *rust-v8-0.49* . Any rust + guix help appreciated.
> >> >>> >>
> >> >>> >> I push the channel to reproduce the problem here :
> >> >>> >>
> >> >>> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
> >> >>> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
> >> >>> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
> >> >>> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
> >> >>> >>
> >> >>> >> And the rust error :
> >> >>> >>
> >> >>> >> —
> >> >>> >>
> >> >>> >> error: failed to run custom build command for `v8 v0.49.0`
> >> >>> >>
> >> >>> >> Caused by:
> >> >>> >>    process didn’t exit successfully: `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build` (exit status: 101)
> >> >>> >>    — stdout
> >> >>> >>    cargo:rerun-if-changed=.gn
> >> >>> >>    cargo:rerun-if-changed=BUILD.gn
> >> >>> >>    cargo:rerun-if-changed=src/binding.cc
> >> >>> >>    cargo:rerun-if-env-changed=CCACHE
> >> >>> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
> >> >>> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
> >> >>> >>    cargo:rerun-if-env-changed=DOCS_RS
> >> >>> >>    cargo:rerun-if-env-changed=GN
> >> >>> >>    cargo:rerun-if-env-changed=GN_ARGS
> >> >>> >>    cargo:rerun-if-env-changed=HOST
> >> >>> >>    cargo:rerun-if-env-changed=NINJA
> >> >>> >>    cargo:rerun-if-env-changed=OUT_DIR
> >> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
> >> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
> >> >>> >>    cargo:rerun-if-env-changed=SCCACHE
> >> >>> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
> >> >>> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
> >> >>> >>    cargo:rustc-link-lib=static=rusty_v8
> >> >>> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
> >> >>> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
> >> >>> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
> >> >>> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
> >> >>> >>    Python downloader failed, trying with curl.  
> >> >>> > Looks like you need to patch rust-v8-0.49 to not try to download
> >> >>> > librusty_v8_release… but instead you’ll have to build it from source
> >> >>> > and let it know where to find it.
> >> >>> >  
> >> >>> >>    — stderr
> >> >>> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
> >> >>> >> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
> >> >>> >> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
> >> >>> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> >> >>> >> warning: build failed, waiting for other jobs to finish…
> >> >>> >> error: build failed
> >> >>> >> error: in phase ’build’: uncaught exception:
> >> >>> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
> >> >>> >> phase `build’ failed after 105.5 seconds
> >> >>> >> command “cargo” “build” “–release” failed with status 101
> >> >>> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
> >> >>> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
> >> >>> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
> >> >>> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed  
> >> >>> >  
> >> >>
> >> >>  
> >> >  
> >
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 25674 bytes --]

Wojtek Kosior <koszko@koszko.org> writes:

>> Yes, you’re right i correct this thing, but this is weird in all case, here i
> clone all deno repository (at tag v1.25.2), and this is renamed as
> `deno-test-util-checkout-0-1-0’ because i’m only interested by this folder
>>
>> <https://git.sr.ht/~reyman/rust-channel/commit/00e9ef93bbe5a853b8a196305b6d86451c036156>
>
> Ah, I see why you wanted a name like this. Well, since the sources are
> the same as those of rust-deno, perhaps it would make sense to use the
> same origin as in rust-deno recipe?
>
> But don’t worry about this now. Your build of rust-deno-test-util
> evidently worked so cleaning up origin definitions can wait until
> everything else works :)
>
>> I found only one crate that use this method `git-fetch’ in the list :
>> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>
>
> There are plenty in other package definition files, e.g. in
> gnu/packages/python-xyz.scm. It seems Rust is just that special case
> where git checkout is rarely needed.

Yes,  i’m not sure this case (source only without crate) is well managed by the actual cargo-build-system ?
Anyway, discussions about “Rust Packaging” on IRC mention the building of a new system, something cargo-less.

>
>> So i suppose this is possible to reuse as a dependency in another build…
>>
>> This is an intuition but i think i have a problem of ordering in my way to do things :
>>
>> When i read the `cargo-build-system’ sources here (
> <https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm#L76>
> ) i see that the build input wait for an /gnu/store link that contain a `.crate’
> or the equivalent as `tar.gz’
>>
>> Or in my case, the /gnu/store link called by cargo contain only sources,
> because the `deno-util’ need to be built before creating .crate into the
> gnu/store. Perhaps i could cheating the system by providing myself a
> `gnu/store/xxxx.tar.gz’ that contain this sources.
>>
>> Inside my `rust-deno-test-util-1-0-0.scm` file i could `(invoke tar …)’
> command to generate a tar.gz at the root of the this folder. Do you think that
> could work ?
>>
>> Hum, not sure … the real problem is the fact that guix don’t build the
> derivation completely? (creating and storing a .crate for deno-test-util-0-1-0
> into /gnu/store) when i run build of main rust-deno.scm … only the source are
> present, and not the package resulting from the build of this derivation.
>>
>> Another way is to first compile deno-test-util.scm, that install the
> corresponding crate into /gnu/store, and after that i give this local path to
> the inputs of my main rust-deno.scm . But i don’t know how to give this path to
> my cargo build system input .
>
> I’m getting a bit lost in trying to figure out what you think right
> now. The
> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/`
> was a proper build of your `rust-deno-test-util` package and it
> contains a proper crate under `share/cargo/registry/`. Code in
> `cargo-build-system.scm` looks for crates in subdirectory
> `share/cargo/registry/` of every rust input package — all seems correct
> under the assumption that we want test_util to be supplied to deno
> build as a separate Guix package.
>
> It’s perhaps possible to achieve success with this assumption (I don’t
> know) but I wanted to instead suggest not creating a separate Guix
> package nor derivation for test_util. That’s what I meant when I wrote
> “it seems awkward to be required to provide the test_util package as a
> separate crate”. Sorry if I accidently mislead you with this.
>

Yes you’re right, this is probably awkard to maintain.

Hum, i will retry. What’s motivating me to try this packaging way is the duration of compilation…
This fail only occur at the test phase, so after 2 hours of compilation…

When i use the “–keep-failed” option, and run a new build after fail from the /tmp/guix-deno-xxx/ folder, everything finish well …

So this is more a problem at frontier between this nested package and “cargo-build-system” that don’t run some nested crate build.

> Earlier you wrote
>
>> This nested crate package is not detected/compiled by actual
>> `cargo-build-system’, so i decide to package it myself , as
>> `rust-deno-test-util-0.1.0’
>
> What seems to be the most straightforward and promising way is to
> (somehow?) fix the build system to detect the nested package. I know,
> it’s easy to say — and you surely made extensive attempts before
> falling back to creating an extra definition for rust-deno-test-util.
> Hopefully, inspection of the build container will help shed some light
> on this.
>
> Also, the git-fetch issues will become nonexistent if you manage to do
> it this way :)
>

I will revert my code to manage the deno compilation without test phase.
My objective is quarto, and i don’t know much about the next obstacle :)
I see later for this nested crate.

> Since your rust-deno recipe uses `(method url-fetch)` with
> `(crate-uri)`, I’m starting to wonder if the tarball that’s being used
> in this case contains exactly the same files as the git checkout. I
> earlier assumed that it does when I suggested reusing the origin in
> your rust-deno-test-util recipe. But perhaps it doesn’t? I could
> imagine deno devs omitting e.g. `test_util/` from the source tarball
> they upload to the crates repo.:

As <https://github.com/denoland/deno/blob/v1.25.2/Cargo.toml#L5> say, the `deno_root_package/test_util/' folder is well downloaded even with `method url-fetch'

>
>> How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?
>
> You don’t :)
>
> That’s the point of a functional package manager - there’s never need
> to *explicitly* reference files in the store. They are always referenced
> indirectly through packages, derivations, plain-file’s, gexps, etc. And
> they get created or reused automatically.
>

So you directly say into the scm, passing this unique path `/gnu/store/xxxxx-deno-util-1-0-1' to input function ??

Thanks for your support and your kind word, that help me to continue :)

Best

> Wojtek
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #25: blessed Maksymilian Binkiewicz
> Poznaj świętych krakowskich!  #25: błogosławiony Maksymilian Binkiewicz
> <https://pl.wikipedia.org/wiki/Maksymilian_Binkiewicz>
> – (sig_end)
>
>
> On Wed, 14 Dec 2022 17:16:45 +0100
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Wojtek Kosior <koszko@koszko.org> writes:
>>
>>
>> > Hello again
>> >
>> > I am impressed with your determination :)
>> >
>>
>> thx :D
>>
>> > I see most packages in Guix that use `(method git-fetch)` also use
>> > `(file-name (git-file-name name version))` in `(origin)`.
>> >
>> > Note that this only affects the name under which the git checkout is
>> > saved. Whether the source checkout directory under `/gnu/store` is
>> > named `8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/`
>> > or something else should not be relevant to the build.
>> >
>>
>> Yes, you’re right i correct this thing, but this is weird in all case, here i
> clone all deno repository (at tag v1.25.2), and this is renamed as
> `deno-test-util-checkout-0-1-0’ because i’m only interested by this folder
>>
>> <https://git.sr.ht/~reyman/rust-channel/commit/00e9ef93bbe5a853b8a196305b6d86451c036156>
>>
>> I found only one crate that use this method `git-fetch’ in the list :
>> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>
>>
>> So i suppose this is possible to reuse as a dependency in another build…
>>
>> This is an intuition but i think i have a problem of ordering in my way to do things :
>>
>> When i read the `cargo-build-system’ sources here (
> <https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm#L76>
> ) i see that the build input wait for an /gnu/store link that contain a `.crate’
> or the equivalent as `tar.gz’
>>
>> Or in my case, the /gnu/store link called by cargo contain only sources,
> because the `deno-util’ need to be built before creating .crate into the
> gnu/store. Perhaps i could cheating the system by providing myself a
> `gnu/store/xxxx.tar.gz’ that contain this sources.
>>
>> Inside my `rust-deno-test-util-1-0-0.scm` file i could `(invoke tar …)’
> command to generate a tar.gz at the root of the this folder. Do you think that
> could work ?
>>
>> Hum, not sure … the real problem is the fact that guix don’t build the
> derivation completely? (creating and storing a .crate for deno-test-util-0-1-0
> into /gnu/store) when i run build of main rust-deno.scm … only the source are
> present, and not the package resulting from the build of this derivation.
>>
>> Another way is to first compile deno-test-util.scm, that install the
> corresponding crate into /gnu/store, and after that i give this local path to
> the inputs of my main rust-deno.scm . But i don’t know how to give this path to
> my cargo build system input . How do you reference/call/reuse a package that
> already exist in your /gnu/store in a .scm file ?
>>
>> > Although I doubt I will be able to help with no knowledge of Rust, I’ll
>> > at least suggest that you attach the full rust-deno build logs here.
>> > This will perhaps at least enable others to help (the time needed to
>> > build it all does scare away!).
>> >
>> > Btw, it seems awkward to be required to provide the test_util package
>> > as a separate crate. I’d rather imagine Deno devs somehow using the
>> > test_util sources already in the deno tree.
>> >
>>
>> Yeah, but now it’s packaged and the package compile, i try one more time like that :D
>>
>> > Have you tried fiddling around inside the build container? If not, you
>> > may want to look at this manual node[1]. Perhaps after running some of
>> > the build commands manually you’ll get better ideas?
>>
>> Thanks i will look on that
>> >
>> > At the end, in the worst case, you could resort to disabling tests for
>> > the package. Nobody likes this “solution” but sometimes it is the only
>> > way to go ¯\_(ツ)_/¯
>>
>> Ahah right, i probably do that if i want to finish in 2022 :D
>>
>> Best,
>> Sébastien Rey-Coyrehourcq
>>
>> >
>> > Good luck,
>> > Wojtek
>> >
>> > [1] <https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html>
>> >
>> > – (sig_start)
>> > website: <https://koszko.org/koszko.html>
>> > PGP: <https://koszko.org/key.gpg>
>> > fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >
>> > Meet Kraków saints!           #24: blessed Ludwik Pius Bartosik
>> > Poznaj świętych krakowskich!  #24: błogosławiony Ludwik Pius Bartosik
>> > <https://pl.wikipedia.org/wiki/Ludwik_Pius_Bartosik>
>> > – (sig_end)
>> >
>> >
>> > On Wed, 14 Dec 2022 11:30:16 +0100
>> > Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>> >
>> >> Hi,
>> >>
>> >> After two weeks of suffering and pain with this complex rust packaging, and
>> >> thanks to people on the libera #guix chat, my “rust packaging adventure” is
>> >> near ending… at least with deno, i see quarto after that…
>> >>
>> >> Everything compile by parts, and i need a final help to merge things.
>> >>
>> >> I only have a problem at `testing-phase’, with a local rust package defined
> on Deno `/test_util’ folder. This package is not published at all on crates.io
> and it’s needed at test-phase…
>> >>
>> >> This nested crate package is not detected/compiled by actual `cargo-build-system’, so i decide to package it myself , as `rust-deno-test-util-0.1.0’
>> >>
>> >> I tested and this crate compile well, with two derivation :
>> >>
>> >> • `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/’
>> >> • `/gnu/store/zp5flzykz7y5n35kqrlryqkynvrvcw3z-rust-deno-test-util-0.1.0.drv’
>> >>
>> >> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/’  contain the test_util-0.1.0.crate
>> >>
>> >> So … i added this *.scm* to my *deno/deno-dep* list of package in the *rust-channel* needed by deno to compile :
>> >> <https://git.sr.ht/~reyman/rust-channel/tree/543fee4cc3626ae27da5b41a7884cecb71b9dcf8/item/deno-dep/rust-deno-test-util-0-1-0.scm>
>> >>
>> >> *My problem is simple?* i added this crate as a dependency of my main `rust-deno.scm’ :
>> >> • `#:use-module (deno-dep rust-deno-test-util-0-1-0)’
>> >> • `#:cargo-development-inputs `(((“rust-deno-test-util”, rust-deno-test-util-0.1.0) … )’
>> >>
>> >> BUT BUT BUT … rust-deno-test-util is not found and not added to `/guix-vendor’
>> >> during deno crate retrieval, so there is a problem somewhere during packaging
>> >> retrieval from local `/gnu/store’. I found in the log that
>> >>
>> >> `/gnu/store/8479xfpn9hp2b3kc9d3596kpncan9d8w-rust-deno-test-util-0.1.0.tar.gz/’
>> >> contain the sources and not a `tar.gz’ like others crates. I suppose this is
>> >> part of the problem, but i don’t know how to solve that.
>> >>
>> >> See by yourself using :
>> >>
>> >> guix time-machine -C channels.scm – build -f rust-deno.scm
>> >>
>> >> that return :
>> >>
>> >> error: no matching package named `deno_test_util` found
>> >>
>> >> **Info to reproduce**
>> >>
>> >> • All these package needed by Deno are defined into my-rust channel here : <https://git.sr.ht/~reyman/rust-channel>
>> >> • The building and channel scm needed to build deno are here : <https://git.sr.ht/~reyman/build-deno-guix>
>> >> • /Final Warning :/ Deno build (outside rust build) take at least 2 hours on my machine, rusty-v8 is huge and take itself ~30 to 45 minutes.
>> >>
>> >> Any *final* help appreciated !
>> >>
>> >> Best ,
>> >> Sébastien Rey-Coyrehourcq
>> >>
>> >>
>> >> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:
>> >>
>> >> >
>> >> > Hi,
>> >> >
>> >> > Thanks a lot, that helps me to make one more step :)
>> >> >
>> >> > I set :
>> >> >
>> >> > ┌────
>> >> > │     (arguments
>> >> > │         `(#:phases
>> >> > │            (modify-phases %standard-phases
>> >> > │          (add-before ’configure ’set-source
>> >> > │            (lambda _
>> >> > │              (setenv “V8_FROM_SOURCE” “1”)
>> >> > │              (setenv “RUST_BACKTRACE” “1”)
>> >> > │              (setenv “CLANG_BASE_PATH” (getenv “CMAKE_PREFIX_PATH”))
>> >> > │              #t)))
>> >> > └────
>> >> >
>> >> > I also try C_INCLUDE_PATH
>> >> >
>> >> > and native input :
>> >> >
>> >> > ┌────
>> >> > │ 	(native-inputs (list ninja gn clang-toolchain ccache clang))
>> >> > └────
>> >> >
>> >> > I have now another problem during compilation of v8, i don’t understand
> why “clang” path is not well recognized by the buildscript, test is defined here
> :
>> >> >
>> >> > <https://github.com/denoland/rusty_v8/blob/main/build.rs#L517>
>> >> >
>> >> > The backtrace :
>> >> >
>> >> > error: failed to run custom build command for `v8 v0.49.0`
>> >> >
>> >> > Caused by:
>> >> > process didn’t exit successfully:
> `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build`
> (exit status: 101)
>> >> >   — stdout
>> >> >   cargo:rerun-if-changed=.gn
>> >> >   cargo:rerun-if-changed=BUILD.gn
>> >> >   cargo:rerun-if-changed=src/binding.cc
>> >> >   cargo:rerun-if-env-changed=CCACHE
>> >> >   cargo:rerun-if-env-changed=CLANG_BASE_PATH
>> >> >   cargo:rerun-if-env-changed=DENO_TRYBUILD
>> >> >   cargo:rerun-if-env-changed=DOCS_RS
>> >> >   cargo:rerun-if-env-changed=GN
>> >> >   cargo:rerun-if-env-changed=GN_ARGS
>> >> >   cargo:rerun-if-env-changed=HOST
>> >> >   cargo:rerun-if-env-changed=NINJA
>> >> >   cargo:rerun-if-env-changed=OUT_DIR
>> >> >   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>> >> >   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>> >> >   cargo:rerun-if-env-changed=SCCACHE
>> >> >   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>> >> >   cargo:rerun-if-env-changed=V8_FROM_SOURCE
>> >> >   cargo:rustc-link-lib=static=rusty_v8
>> >> >   using Chromiums clang
>> >> >   clang_base_path /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/clang
>> >> >
>> >> > — stderr
>> >> > thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:537:6
>> >> > stack backtrace:
>> >> >    0: rust_begin_unwind
>> >> >    1: core::panicking::panic_fmt
>> >> >    2: core::result::unwrap_failed
>> >> >    3: core::result::Result<T,E>::unwrap
>> >> >    4: build_script_build::clang_download
>> >> >    5: build_script_build::build_v8
>> >> >    6: build_script_build::main
>> >> >    7: core::ops::function::FnOnce::call_once
>> >> > note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
>> >> >
>> >> > Best,
>> >> >
>> >> >
>> >> > Wojtek Kosior <koszko@koszko.org> writes:
>> >> >
>> >> >>> Hi,
>> >> >>>
>> >> >>> You’re both right, seems there is a flag to skip binary downloading and
>> >> >>> compile the V8 lib.
>> >> >>>
>> >> >>> […]
>> >> >>
>> >> >> Good to see you found it :)
>> >> >>
>> >> >>> So, my packaging friend :), what’s the best way to push an “export
>> >> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>> >> >>>
>> >> >>> Best,
>> >> >>>
>> >> >>> SR
>> >> >>
>> >> >> When I first read your question, I did not know the exact function. But
>> >> >> I knew where to look. So I thought I’d better share my way of learning
>> >> >> rather than just the solution ;)
>> >> >>
>> >> >> I started with
>> >> >>
>> >> >>     grep -R ’export’ ~/.config/guix/current/share/guile/site/3.0/gnu/packages/ | less
>> >> >>
>> >> >> That showed a lot of results. I noticed a line like this
>> >> >>
>> >> >>>
> /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm:
> (setenv “HOME” (getcwd)) ;; cmake needs this to export modules
>> >> >>
>> >> >> Thought it might be the thing I was looking for, so I did
>> >> >>
>> >> >>     less /home/urz/.config/guix/current/share/guile/site/3.0/gnu/packages/engineering.scm
>> >> >>
>> >> >> and navigated to this line. This seems to be it. The (setenv) function.
>> >> >> Can be used as from a modified packaging phase function (as you can see
>> >> >> in engineering.scm).
>> >> >>
>> >> >> Hope I helped. Good luck once again!
>> >> >>
>> >> >> W.
>> >> >>
>> >> >> P.S. Make sure you know some ’less’ shortcuts if you’re going to do
>> >> >>      things this way. It cad speed things up ^^
>> >> >>
>> >> >> – (sig_start)
>> >> >> website: <https://koszko.org/koszko.html>
>> >> >> PGP: <https://koszko.org/key.gpg>
>> >> >> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>> >> >>
>> >> >> Meet Kraków saints!           #12: saint Jadwiga Andegaweńska
>> >> >> Poznaj świętych krakowskich!  #12: święta Jadwiga Andegaweńska
>> >> >> <https://pl.wikipedia.org/wiki/Jadwiga_Andegaweńska>
>> >> >> – (sig_end)
>> >> >>
>> >> >>
>> >> >> On Wed, 16 Nov 2022 21:38:47 +0100
>> >> >> Sebastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>> >> >>
>> >> >>> Hi,
>> >> >>>
>> >> >>> You’re both right, seems there is a flag to skip binary downloading and
>> >> >>> compile the V8 lib.
>> >> >>>
>> >> >>>  From the githubpage (<https://github.com/denoland/rusty_v8>) : “V8 is
>> >> >>> very large and takes a long time to compile. Many users will prefer to
>> >> >>> use a prebuilt version of V8. We publish static libs for every version
>> >> >>> of rusty v8 on Github <https://github.com/denoland/rusty_v8/releases>.
>> >> >>>
>> >> >>> Binaries builds are turned on by default: |cargo build| will initiate a
>> >> >>> download from github to get the static lib. To disable this build using
>> >> >>> the |V8_FROM_SOURCE| environmental variable.
>> >> >>>
>> >> >>> When making changes to rusty_v8 itself, it should be tested by build
>> >> >>> from source. The CI always builds from source”
>> >> >>>
>> >> >>> So, my packaging friend :), what’s the best way to push an “export
>> >> >>> V8_FROM_SOURCE=1” or something like that into my rust-deno.scm ?
>> >> >>>
>> >> >>> Best,
>> >> >>>
>> >> >>> SR
>> >> >>>
>> >> >>> Le 15/11/2022 à 08:58, Efraim Flashner a écrit :
>> >> >>> > On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:
>> >> >>> >> Hi,
>> >> >>> >>
>> >> >>> >> After some day of packaging rust crate, i progress and deno start to
>> >> >>> >> compile … but after 1min i have this error when cargo start compiling
>> >> >>> >> *rust-v8-0.49* . Any rust + guix help appreciated.
>> >> >>> >>
>> >> >>> >> I push the channel to reproduce the problem here :
>> >> >>> >>
>> >> >>> >> The rust scm repo : git.sr.ht:~reyman/rust-channel
>> >> >>> >> Channel info to put into *channels.scm* :<https://paste.debian.net/1260722>
>> >> >>> >> The *rust-deno.scm* file to build :<https://paste.debian.net/1260723>
>> >> >>> >> The command : guix time-machine -C channels.scm – build -f rust-deno.scm
>> >> >>> >>
>> >> >>> >> And the rust error :
>> >> >>> >>
>> >> >>> >> —
>> >> >>> >>
>> >> >>> >> error: failed to run custom build command for `v8 v0.49.0`
>> >> >>> >>
>> >> >>> >> Caused by:
>> >> >>> >> process didn’t exit successfully:
> `/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build`
> (exit status: 101)
>> >> >>> >>    — stdout
>> >> >>> >>    cargo:rerun-if-changed=.gn
>> >> >>> >>    cargo:rerun-if-changed=BUILD.gn
>> >> >>> >>    cargo:rerun-if-changed=src/binding.cc
>> >> >>> >>    cargo:rerun-if-env-changed=CCACHE
>> >> >>> >>    cargo:rerun-if-env-changed=CLANG_BASE_PATH
>> >> >>> >>    cargo:rerun-if-env-changed=DENO_TRYBUILD
>> >> >>> >>    cargo:rerun-if-env-changed=DOCS_RS
>> >> >>> >>    cargo:rerun-if-env-changed=GN
>> >> >>> >>    cargo:rerun-if-env-changed=GN_ARGS
>> >> >>> >>    cargo:rerun-if-env-changed=HOST
>> >> >>> >>    cargo:rerun-if-env-changed=NINJA
>> >> >>> >>    cargo:rerun-if-env-changed=OUT_DIR
>> >> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
>> >> >>> >>    cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
>> >> >>> >>    cargo:rerun-if-env-changed=SCCACHE
>> >> >>> >>    cargo:rerun-if-env-changed=V8_FORCE_DEBUG
>> >> >>> >>    cargo:rerun-if-env-changed=V8_FROM_SOURCE
>> >> >>> >>    cargo:rustc-link-lib=static=rusty_v8
>> >> >>> >>    download lockfile: “/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
>> >> >>> >>    static lib URL:<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>> >> >>> >>    cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
>> >> >>> >>    Downloading<https://github.com/denoland/rusty_v8/releases/download/v0.49.0/librusty_v8_release_x86_64-unknown-linux-gnu.a>
>> >> >>> >>    Python downloader failed, trying with curl.
>> >> >>> > Looks like you need to patch rust-v8-0.49 to not try to download
>> >> >>> > librusty_v8_release… but instead you’ll have to build it from source
>> >> >>> > and let it know where to find it.
>> >> >>> >
>> >> >>> >>    — stderr
>> >> >>> >>    thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value:
>> >> >>> >> Os { code: 2, kind: NotFound, message: “No such file or directory” }’,
>> >> >>> >> /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
>> >> >>> >>    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
>> >> >>> >> warning: build failed, waiting for other jobs to finish…
>> >> >>> >> error: build failed
>> >> >>> >> error: in phase ’build’: uncaught exception:
>> >> >>> >> %exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) exit-status: 101 term-signal: #f stop-signal: #f>
>> >> >>> >> phase `build’ failed after 105.5 seconds
>> >> >>> >> command “cargo” “build” “–release” failed with status 101
>> >> >>> >> builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed with exit code 1
>> >> >>> >> la compilation de /gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
>> >> >>> >> Vous trouverez le journal de compilation dans « /var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
>> >> >>> >> guix build: erreur : build of `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 10397 bytes --]

Hi,

I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D

┌────
│ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno --version
│ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
│ v8 10.6.194.5
│ typescript 4.7.4
│ 
│ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
│ Hello John
│ Hello Sarah
│ Hello Kai
│ 
└────

Next steps :
• Packaging Quarto (that need Deno).
• Merge and Cleaning mess with dependency.

If you want to try :
<https://git.sr.ht/~reyman/build-deno-guix>

Best regards,
SR

“Sebastien Rey-Coyrehourcq” <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:

>
> Le Lundi, Octobre 24, 2022 13:43 CEST, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> a écrit:
>
>> Hi,
>>
>> I’m trying to package Quarto Cli ( <https://github.com/quarto-dev/quarto-cli> ), used in combination with Pandoc to publish -reproducible- scientific document : website, blog, etc.
>>
>> I first think this is a classic gnu build : ./configure && make && make install BUT, there is a problem because the ./configure script bootstrap “Deno” during the run of configure.sh.
>>
>> Because this download and compilation of Deno occur during ./configure.sh running, guix cannot patch the  #!/bin/bash path, so ./configure failed. Deno seems also not packaged into guix.
>>
>> Do you have an idea to resolve this ? Perhaps we could try all together to do this.
>>
>> I’m starting with this quarto-cli.scm :
>>
>> ┌────
>> │ (use-modules
>> │ (guix packages)
>> │ (guix download)
>> │ (guix build-system gnu)
>> │ (guix licenses)
>> │ )
>> │
>> │ (define-public quarto-cli
>> │   (package
>> │     (name “Quarto-CLI”)
>> │     (version “1.1.251”)
>> │     (source (origin
>> │               (method url-fetch)
>> │               (uri (string-append “<https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz>”))
>> │               (sha256
>> │                (base32
>> │                 “1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6”))))
>> │     (build-system gnu-build-system)
>> │     (synopsis “Quarto-cli”)
>> │     (description
>> │      “Quarto-cli description”)
>> │     (home-page “<https://github.com/quarto-dev/quarto-cli>”)
>> │     (license gpl3+)))
>> │ quarto-cli
>> │
>> └────
>>
>> To compile and fail :
>> guix build -f quarto-cli.scm
>>
>> Best,
>> Sebastien RC.
>
> Deno contain lot of packages dependencies actually,
> here i comment all packages not packaged in rust after a simple run of guix import …
>
> #+BEGIN_SRC scheme
>
> (use-modules
> (guix packages)
> (guix build-system cargo)
> (guix download)
> (guix licenses)
> (gnu packages rust)
> (gnu packages crates-io)
> )
>
> (define-public rust-deno-1
>   (package
>     (name “rust-deno”)
>     (version “1.26.2”)
>     (source (origin
>               (method url-fetch)
>               (uri (crate-uri “deno” version))
>               (file-name (string-append name “-” version “.tar.gz”))
>               (sha256
>                (base32
>                 “1yzvdkj8sq475kfbkms1lfysjddkfwcyqhp1ggalfbk4hqhbiz29”))))
>     (build-system cargo-build-system)
>     (arguments
>      `(#:cargo-inputs ((“rust-atty” ,rust-atty-0.2)
>                        (“rust-base64” ,rust-base64-0.13)
> ;                       (“rust-cache-control” ,rust-cache-control-0.2)
>                         (“rust-chrono” ,rust-chrono-0.4)
> ;                       (“rust-clap” ,rust-clap-3)
> ;                       (“rust-clap-complete” ,rust-clap-complete-3)
> ;                       (“rust-clap-complete-fig” ,rust-clap-complete-fig-3)
>                         (“rust-data-url” ,rust-data-url-0.1)
> ;                       (“rust-deno-ast” ,rust-deno-ast-0.19)
> ;                       (“rust-deno-broadcast-channel” ,rust-deno-broadcast-channel-0.67)
> ;                       (“rust-deno-cache” ,rust-deno-cache-0.5)
> ;                       (“rust-deno-console” ,rust-deno-console-0.73)
> ;                       (“rust-deno-core” ,rust-deno-core-0.155)
> ;                       (“rust-deno-core” ,rust-deno-core-0.155)
> ;                       (“rust-deno-crypto” ,rust-deno-crypto-0.87)
> ;                       (“rust-deno-doc” ,rust-deno-doc-0.46)
> ;                       (“rust-deno-emit” ,rust-deno-emit-0.9)
> ;                       (“rust-deno-fetch” ,rust-deno-fetch-0.96)
> ;                       (“rust-deno-graph” ,rust-deno-graph-0.34)
> ;                       (“rust-deno-lint” ,rust-deno-lint-0.33)
> ;                       (“rust-deno-net” ,rust-deno-net-0.65)
> ;                       (“rust-deno-node” ,rust-deno-node-0.10)
> ;                       (“rust-deno-runtime” ,rust-deno-runtime-0.81)
> ;                       (“rust-deno-task-shell” ,rust-deno-task-shell-0.5)
> ;                       (“rust-deno-url” ,rust-deno-url-0.73)
> ;                       (“rust-deno-web” ,rust-deno-web-0.104)
> ;                       (“rust-deno-webgpu” ,rust-deno-webgpu-0.74)
> ;                       (“rust-deno-websocket” ,rust-deno-websocket-0.78)
> ;                       (“rust-deno-webstorage” ,rust-deno-webstorage-0.68)
>                        (“rust-dissimilar” ,rust-dissimilar-1)
> ;                       (“rust-dprint-plugin-json” ,rust-dprint-plugin-json-0.15)
> ;                       (“rust-dprint-plugin-markdown” ,rust-dprint-plugin-markdown-0.14)
> ;                       (“rust-dprint-plugin-typescript” ,rust-dprint-plugin-typescript-0.74)
>                        (“rust-encoding-rs” ,rust-encoding-rs-0.8)
>                        (“rust-env-logger” ,rust-env-logger-0.9)
> ;                       (“rust-eszip” ,rust-eszip-0.28)
> ;                       (“rust-fancy-regex” ,rust-fancy-regex-0.10)
>                        (“rust-flate2” ,rust-flate2-1)
>                        (“rust-fwdansi” ,rust-fwdansi-1)
> ;                       (“rust-glibc-version” ,rust-glibc-version-0.1)
>                        (“rust-http” ,rust-http-0.2)
> ;                       (“rust-import-map” ,rust-import-map-0.12)
>                        (“rust-indexmap” ,rust-indexmap-1)
> ;                       (“rust-indicatif” ,rust-indicatif-0.17)
> ;                       (“rust-jsonc-parser” ,rust-jsonc-parser-0.21)
> ;                       (“rust-junction” ,rust-junction-0.2)
>                        (“rust-libc” ,rust-libc-0.2)
>                        (“rust-log” ,rust-log-0.4)
> ;                       (“rust-mitata” ,rust-mitata-0.0.7)
> ;                       (“rust-monch” ,rust-monch-0.2)
> ;                       (“rust-napi-sym” ,rust-napi-sym-0.3)
>                        (“rust-notify” ,rust-notify-5)
>                        (“rust-once-cell” ,rust-once-cell-1)
>                        (“rust-os-pipe” ,rust-os-pipe-1)
>                        (“rust-percent-encoding” ,rust-percent-encoding-2)
>                        (“rust-pin-project” ,rust-pin-project-1)
>                        (“rust-rand” ,rust-rand-0.8)
>                        (“rust-regex” ,rust-regex-1)
>                        (“rust-regex” ,rust-regex-1)
>                        (“rust-ring” ,rust-ring-0.16)
> ;                       (“rust-rustyline” ,rust-rustyline-10)
> ;                       (“rust-rustyline-derive” ,rust-rustyline-derive-0.7)
>                        (“rust-semver” ,rust-semver-1)
>                        (“rust-serde” ,rust-serde-1)
>                        (“rust-serde” ,rust-serde-1)
>                        (“rust-serde-json” ,rust-serde-json-1)
>                        (“rust-serde-repr” ,rust-serde-repr-0.1)
>                        (“rust-shell-escape” ,rust-shell-escape-0.1)
>                        (“rust-tar” ,rust-tar-0.4)
>                        (“rust-tempfile” ,rust-tempfile-3)
>                        (“rust-text-size” ,rust-text-size-1)
> ;                       (“rust-text-lines” ,rust-text-lines-0.6)
>                        (“rust-tokio” ,rust-tokio-1)
> ;                       (“rust-tokio-util” ,rust-tokio-util-0.7)
> ;                       (“rust-tower-lsp” ,rust-tower-lsp-0.17)
>                        (“rust-twox-hash” ,rust-twox-hash-1)
>                        (“rust-typed-arena” ,rust-typed-arena-2)
> ;                       (“rust-uuid” ,rust-uuid-1)
>                        (“rust-walkdir” ,rust-walkdir-2)
>                        (“rust-winapi” ,rust-winapi-0.3)
>                        (“rust-winapi” ,rust-winapi-0.3)
>                        (“rust-winres” ,rust-winres-0.1)
> ;                      (“rust-zstd” ,rust-zstd-0.11)
>                        )
>        #:cargo-development-inputs (
>                                    ;(“rust-deno-bench-util” ,rust-deno-bench-util-0.67)
>                                    (“rust-dotenv” ,rust-dotenv-0.15)
>                                    ;(“rust-flaky-test” ,rust-flaky-test-0.1)
>                                    ;(“rust-nix” ,rust-nix-0.24)
>                                    (“rust-once-cell” ,rust-once-cell-1)
>                                    (“rust-os-pipe” ,rust-os-pipe-1)
>                                    (“rust-pretty-assertions” ,rust-pretty-assertions-1)
>                                    ;(“rust-trust-dns-client” ,rust-trust-dns-client-0.22)
>                                    ;(“rust-trust-dns-server” ,rust-trust-dns-server-0.22))))
>     (home-page “<https://github.com/denoland/deno>”)
>     (synopsis “Provides the deno executable”)
>     (description “This package provides the deno executable”)
>     (license expat)))
>
> rust-deno-1
>
> #+END_SRC
>
>
>
>
>
>
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[zimoun]

Hi,

On Thu, 15 Dec 2022 at 09:32, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
>
> ┌────
> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno --version
> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
> │ v8 10.6.194.5
> │ typescript 4.7.4
> │ 
> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
> │ Hello John
> │ Hello Sarah
> │ Hello Kai
> │ 
> └────

Wow!  Congrats!

Cheers,
simon

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 19389 bytes --]

> >> I found only one crate that use this method `git-fetch’ in the list :
> >> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>  
> >
> > There are plenty in other package definition files, e.g. in
> > gnu/packages/python-xyz.scm. It seems Rust is just that special case
> > where git checkout is rarely needed.  
> 
> Yes,  i’m not sure this case (source only without crate) is well managed by the actual cargo-build-system ?
> Anyway, discussions about “Rust Packaging” on IRC mention the building of a new system, something cargo-less.

What do you mean by "source only without crate"? From my understanding,
even when we use `(method uri-fetch)` with `(crate-uri)`, what gets
downloaded is still just the source code and not a prebuilt crate. The
crates repo serves both the crates and their corresponding source
tarballs, right?

Even though there is a difference from the `(method git-fetch)` case —
the output is a tarball instead of a directory — it's still just source
code and the untaring of it is — I believe — done automatically.

Or it is something else you meant?


> > I wanted to instead suggest not creating a separate Guix package
> > nor derivation for test_util. That’s what I meant when I wrote “it
> > seems awkward to be required to provide the test_util package as a
> > separate crate”. Sorry if I accidently mislead you with this. 
> 
> Yes you’re right, this is probably awkard to maintain.
> 
> Hum, i will retry. What’s motivating me to try this packaging way is
> the duration of compilation… This fail only occur at the test phase,
> so after 2 hours of compilation…
> 
> When i use the “–keep-failed” option, and run a new build after fail
> from the /tmp/guix-deno-xxx/ folder, everything finish well …
> 
> So this is more a problem at frontier between this nested package and
> “cargo-build-system” that don’t run some nested crate build.

Did you *just* run a new build inside `/tmp/guix-deno-xxx/`? Or did you
as well run a `cargo test` or similar command after it? Because I
understand it is `cargo test` invoked by cargo-build-system that is
failing[1].

> I will revert my code to manage the deno compilation without test phase.
> My objective is quarto, and i don’t know much about the next obstacle :)
> I see later for this nested crate.

Yup, it's a sane approach.

> >  
> >> How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?  
> >
> > You don’t :)
> >
> > That’s the point of a functional package manager - there’s never need
> > to *explicitly* reference files in the store. They are always referenced
> > indirectly through packages, derivations, plain-file’s, gexps, etc. And
> > they get created or reused automatically.
> >  
> 
> So you directly say into the scm, passing this unique path `/gnu/store/xxxxx-deno-util-1-0-1' to input function ??

No no no.

Let's recall what you wanted to do in the first place

> Another way is to first compile deno-test-util.scm, that install the
> corresponding crate into /gnu/store, and after that i give this local
> path to the inputs of my main rust-deno.scm . But i don’t know how to
> give this path to my cargo build system input . How do you
> reference/call/reuse a package that already exist in your /gnu/store
> in a .scm file ?

I'd say we already reached the decision that we don't want to make
rust-deno-test-util a distinct guix package. But for the sake of
learning, let's imagine that we do and that we want to reference its
crate manually in another package recipe.

Recall that you had the crate file at
`/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/test_util-0.1.0.crate`.
In the rust-deno recipe you were importing the record describing that
crate's package. It was being imported under the name
`rust-deno-test-util-0.1.0`.

So the `(arguments)` field of the recipe could contain sth like

    #:phases
    #~(modify-phases %standard-phases
        (add-after 'build 'do-sth-with-test-util-crate
          (lambda _
            (do-something-with
             #$(file-append rust-deno-test-util-0.1.0
                            "/share/cargo/registry/test_util-0.1.0.crate")))))

For simplicity I omitted other extra phases that you might put there.
Notice that the phases are now computed using `#~` which is syntactic
sugar for `(gexp)`. Also note that the crate file path gets introduced
with `#$(file-append ...)` where `#$` is syntactic sugar for `ungexp`.
`(file-append)` itself as well as `#~` and `#$` become available when
the `(guix gexp)` module is imported.

This is a relatively low-level, gexp-based approach to using other
packages during the build (and only the build). It probably looks like
black magic now. To better understand it, please consult your copy of
the "Guix black magic" handbook (aka the "G-Expressions" chapter of the
GNU Guix manual[2]).

If rust-deno-test-util was instead meant to be one of the `(inputs)`
(i.e. if it was one of the runtime deps), we could instead use the
following common idiom.

    #:phases
    `(modify-phases %standard-phases
       (add-after 'build 'do-sth-with-test-util-crate
         (lambda* (#:key inputs #:allow-other-keys)
           (let ((test-util (assoc-ref inputs "rust-deno-test-util")))
             (do-something-with
              (string-append test-util
                             "/share/cargo/registry/test_util-0.1.0.crate"))))))

Here I assumed that "rust-deno-test-util" is the name of the
rust-deno-test-util Guix package and that this name is being
automatically used as its key in the inputs association list. It is
possible to explicitly assign different, non-default string keys to the
packages listed among `(inputs)`. It is, however, not highly relevant
now — let's ignore this possibility.

I already showed 2 ways of accessing a file produced by some
prerequisite package/derivation. In both cases Guix shall automatically
recognize that rust-deno-test-util is a prerequisite and build it if it
is not yet present in `/gnu/store`. None of this approaches should be
needed, however. That's because in the case of cargo-build-system the standard
way of providing crates is by listing the required crate packages among
`#:cargo-inputs` or `#:cargo-development-inputs`. Just as you were
doing. cargo-build-system then by itself takes care of collecting the
crates inside the listed packages and instructing the `cargo` command
to find those crates.

I don't know what was still causing the error *after* you placed
rust-deno-test-util among `#:cargo-development-inputs`. I guess the
reason was specific to Deno build system and not to Guix nor to
cargo-build-system.

> Thanks for your support and your kind word, that help me to continue :)

Glad I could help even with my small Guix experience ^^

> Hi,
> 
> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
> 
> ┌────
> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno --version
> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
> │ v8 10.6.194.5
> │ typescript 4.7.4
> │ 
> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
> │ Hello John
> │ Hello Sarah
> │ Hello Kai
> │ 
> └────

Great! 👏

> Next steps :
> • Packaging Quarto (that need Deno).
> • Merge and Cleaning mess with dependency.

Just a question, out of curiosity - are there any serious freedom
issues? I saw you are using some custom Guix channels in addition to
your own one and that made me wonder

Wojtek


[1] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/cargo-build-system.scm?id=408a4ed071c9c52de207d799a698781d49fa727d#n209
[2] https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #16: saint Jan z Dukli
Poznaj świętych krakowskich!  #16: święty Jan z Dukli
https://pl.wikipedia.org/wiki/Jan_z_Dukli
-- (sig_end)


On Thu, 15 Dec 2022 09:32:48 +0100
Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:

> Hi,
> 
> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
> 
> ┌────
> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno --version
> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
> │ v8 10.6.194.5
> │ typescript 4.7.4
> │ 
> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
> │ Hello John
> │ Hello Sarah
> │ Hello Kai
> │ 
> └────
> 
> Next steps :
> • Packaging Quarto (that need Deno).
> • Merge and Cleaning mess with dependency.
> 
> If you want to try :
> <https://git.sr.ht/~reyman/build-deno-guix>
> 
> Best regards,
> SR
> 
> “Sebastien Rey-Coyrehourcq” <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:
> 
> >
> > Le Lundi, Octobre 24, 2022 13:43 CEST, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> a écrit:
> >  
> >> Hi,
> >>
> >> I’m trying to package Quarto Cli ( <https://github.com/quarto-dev/quarto-cli> ), used in combination with Pandoc to publish -reproducible- scientific document : website, blog, etc.
> >>
> >> I first think this is a classic gnu build : ./configure && make && make install BUT, there is a problem because the ./configure script bootstrap “Deno” during the run of configure.sh.
> >>
> >> Because this download and compilation of Deno occur during ./configure.sh running, guix cannot patch the  #!/bin/bash path, so ./configure failed. Deno seems also not packaged into guix.
> >>
> >> Do you have an idea to resolve this ? Perhaps we could try all together to do this.
> >>
> >> I’m starting with this quarto-cli.scm :
> >>
> >> ┌────
> >> │ (use-modules
> >> │ (guix packages)
> >> │ (guix download)
> >> │ (guix build-system gnu)
> >> │ (guix licenses)
> >> │ )
> >> │
> >> │ (define-public quarto-cli
> >> │   (package
> >> │     (name “Quarto-CLI”)
> >> │     (version “1.1.251”)
> >> │     (source (origin
> >> │               (method url-fetch)
> >> │               (uri (string-append “<https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz>”))
> >> │               (sha256
> >> │                (base32
> >> │                 “1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6”))))
> >> │     (build-system gnu-build-system)
> >> │     (synopsis “Quarto-cli”)
> >> │     (description
> >> │      “Quarto-cli description”)
> >> │     (home-page “<https://github.com/quarto-dev/quarto-cli>”)
> >> │     (license gpl3+)))
> >> │ quarto-cli
> >> │
> >> └────
> >>
> >> To compile and fail :
> >> guix build -f quarto-cli.scm
> >>
> >> Best,
> >> Sebastien RC.  
> >
> > Deno contain lot of packages dependencies actually,
> > here i comment all packages not packaged in rust after a simple run of guix import …
> >
> > #+BEGIN_SRC scheme
> >
> > (use-modules
> > (guix packages)
> > (guix build-system cargo)
> > (guix download)
> > (guix licenses)
> > (gnu packages rust)
> > (gnu packages crates-io)
> > )
> >
> > (define-public rust-deno-1
> >   (package
> >     (name “rust-deno”)
> >     (version “1.26.2”)
> >     (source (origin
> >               (method url-fetch)
> >               (uri (crate-uri “deno” version))
> >               (file-name (string-append name “-” version “.tar.gz”))
> >               (sha256
> >                (base32
> >                 “1yzvdkj8sq475kfbkms1lfysjddkfwcyqhp1ggalfbk4hqhbiz29”))))
> >     (build-system cargo-build-system)
> >     (arguments
> >      `(#:cargo-inputs ((“rust-atty” ,rust-atty-0.2)
> >                        (“rust-base64” ,rust-base64-0.13)
> > ;                       (“rust-cache-control” ,rust-cache-control-0.2)
> >                         (“rust-chrono” ,rust-chrono-0.4)
> > ;                       (“rust-clap” ,rust-clap-3)
> > ;                       (“rust-clap-complete” ,rust-clap-complete-3)
> > ;                       (“rust-clap-complete-fig” ,rust-clap-complete-fig-3)
> >                         (“rust-data-url” ,rust-data-url-0.1)
> > ;                       (“rust-deno-ast” ,rust-deno-ast-0.19)
> > ;                       (“rust-deno-broadcast-channel” ,rust-deno-broadcast-channel-0.67)
> > ;                       (“rust-deno-cache” ,rust-deno-cache-0.5)
> > ;                       (“rust-deno-console” ,rust-deno-console-0.73)
> > ;                       (“rust-deno-core” ,rust-deno-core-0.155)
> > ;                       (“rust-deno-core” ,rust-deno-core-0.155)
> > ;                       (“rust-deno-crypto” ,rust-deno-crypto-0.87)
> > ;                       (“rust-deno-doc” ,rust-deno-doc-0.46)
> > ;                       (“rust-deno-emit” ,rust-deno-emit-0.9)
> > ;                       (“rust-deno-fetch” ,rust-deno-fetch-0.96)
> > ;                       (“rust-deno-graph” ,rust-deno-graph-0.34)
> > ;                       (“rust-deno-lint” ,rust-deno-lint-0.33)
> > ;                       (“rust-deno-net” ,rust-deno-net-0.65)
> > ;                       (“rust-deno-node” ,rust-deno-node-0.10)
> > ;                       (“rust-deno-runtime” ,rust-deno-runtime-0.81)
> > ;                       (“rust-deno-task-shell” ,rust-deno-task-shell-0.5)
> > ;                       (“rust-deno-url” ,rust-deno-url-0.73)
> > ;                       (“rust-deno-web” ,rust-deno-web-0.104)
> > ;                       (“rust-deno-webgpu” ,rust-deno-webgpu-0.74)
> > ;                       (“rust-deno-websocket” ,rust-deno-websocket-0.78)
> > ;                       (“rust-deno-webstorage” ,rust-deno-webstorage-0.68)
> >                        (“rust-dissimilar” ,rust-dissimilar-1)
> > ;                       (“rust-dprint-plugin-json” ,rust-dprint-plugin-json-0.15)
> > ;                       (“rust-dprint-plugin-markdown” ,rust-dprint-plugin-markdown-0.14)
> > ;                       (“rust-dprint-plugin-typescript” ,rust-dprint-plugin-typescript-0.74)
> >                        (“rust-encoding-rs” ,rust-encoding-rs-0.8)
> >                        (“rust-env-logger” ,rust-env-logger-0.9)
> > ;                       (“rust-eszip” ,rust-eszip-0.28)
> > ;                       (“rust-fancy-regex” ,rust-fancy-regex-0.10)
> >                        (“rust-flate2” ,rust-flate2-1)
> >                        (“rust-fwdansi” ,rust-fwdansi-1)
> > ;                       (“rust-glibc-version” ,rust-glibc-version-0.1)
> >                        (“rust-http” ,rust-http-0.2)
> > ;                       (“rust-import-map” ,rust-import-map-0.12)
> >                        (“rust-indexmap” ,rust-indexmap-1)
> > ;                       (“rust-indicatif” ,rust-indicatif-0.17)
> > ;                       (“rust-jsonc-parser” ,rust-jsonc-parser-0.21)
> > ;                       (“rust-junction” ,rust-junction-0.2)
> >                        (“rust-libc” ,rust-libc-0.2)
> >                        (“rust-log” ,rust-log-0.4)
> > ;                       (“rust-mitata” ,rust-mitata-0.0.7)
> > ;                       (“rust-monch” ,rust-monch-0.2)
> > ;                       (“rust-napi-sym” ,rust-napi-sym-0.3)
> >                        (“rust-notify” ,rust-notify-5)
> >                        (“rust-once-cell” ,rust-once-cell-1)
> >                        (“rust-os-pipe” ,rust-os-pipe-1)
> >                        (“rust-percent-encoding” ,rust-percent-encoding-2)
> >                        (“rust-pin-project” ,rust-pin-project-1)
> >                        (“rust-rand” ,rust-rand-0.8)
> >                        (“rust-regex” ,rust-regex-1)
> >                        (“rust-regex” ,rust-regex-1)
> >                        (“rust-ring” ,rust-ring-0.16)
> > ;                       (“rust-rustyline” ,rust-rustyline-10)
> > ;                       (“rust-rustyline-derive” ,rust-rustyline-derive-0.7)
> >                        (“rust-semver” ,rust-semver-1)
> >                        (“rust-serde” ,rust-serde-1)
> >                        (“rust-serde” ,rust-serde-1)
> >                        (“rust-serde-json” ,rust-serde-json-1)
> >                        (“rust-serde-repr” ,rust-serde-repr-0.1)
> >                        (“rust-shell-escape” ,rust-shell-escape-0.1)
> >                        (“rust-tar” ,rust-tar-0.4)
> >                        (“rust-tempfile” ,rust-tempfile-3)
> >                        (“rust-text-size” ,rust-text-size-1)
> > ;                       (“rust-text-lines” ,rust-text-lines-0.6)
> >                        (“rust-tokio” ,rust-tokio-1)
> > ;                       (“rust-tokio-util” ,rust-tokio-util-0.7)
> > ;                       (“rust-tower-lsp” ,rust-tower-lsp-0.17)
> >                        (“rust-twox-hash” ,rust-twox-hash-1)
> >                        (“rust-typed-arena” ,rust-typed-arena-2)
> > ;                       (“rust-uuid” ,rust-uuid-1)
> >                        (“rust-walkdir” ,rust-walkdir-2)
> >                        (“rust-winapi” ,rust-winapi-0.3)
> >                        (“rust-winapi” ,rust-winapi-0.3)
> >                        (“rust-winres” ,rust-winres-0.1)
> > ;                      (“rust-zstd” ,rust-zstd-0.11)
> >                        )
> >        #:cargo-development-inputs (
> >                                    ;(“rust-deno-bench-util” ,rust-deno-bench-util-0.67)
> >                                    (“rust-dotenv” ,rust-dotenv-0.15)
> >                                    ;(“rust-flaky-test” ,rust-flaky-test-0.1)
> >                                    ;(“rust-nix” ,rust-nix-0.24)
> >                                    (“rust-once-cell” ,rust-once-cell-1)
> >                                    (“rust-os-pipe” ,rust-os-pipe-1)
> >                                    (“rust-pretty-assertions” ,rust-pretty-assertions-1)
> >                                    ;(“rust-trust-dns-client” ,rust-trust-dns-client-0.22)
> >                                    ;(“rust-trust-dns-server” ,rust-trust-dns-server-0.22))))
> >     (home-page “<https://github.com/denoland/deno>”)
> >     (synopsis “Provides the deno executable”)
> >     (description “This package provides the deno executable”)
> >     (license expat)))
> >
> > rust-deno-1
> >
> > #+END_SRC
> >
> >
> >
> >
> >
> >
> >
> >  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Help packaging R Quarto Cli

[Sébastien Rey-Coyrehourcq]

[-- Attachment #1.1.1: Type: text/plain, Size: 28575 bytes --]

Hi,

Wojtek Kosior <koszko@koszko.org> writes:


>> >> I found only one crate that use this method `git-fetch’ in the list :
>> >> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>
>> >
>> > There are plenty in other package definition files, e.g. in
>> > gnu/packages/python-xyz.scm. It seems Rust is just that special case
>> > where git checkout is rarely needed.
>>
>> Yes,  i’m not sure this case (source only without crate) is well managed by the actual cargo-build-system ?
>> Anyway, discussions about “Rust Packaging” on IRC mention the building of a new system, something cargo-less.
>
> What do you mean by “source only without crate”? From my understanding,
> even when we use `(method uri-fetch)` with `(crate-uri)`, what gets
> downloaded is still just the source code and not a prebuilt crate. The
> crates repo serves both the crates and their corresponding source
> tarballs, right?
>
> Even though there is a difference from the `(method git-fetch)` case —
> the output is a tarball instead of a directory — it’s still just source
> code and the untaring of it is — I believe — done automatically.
>
> Or it is something else you meant?
>

Yes, you’re right.

>
>> > I wanted to instead suggest not creating a separate Guix package
>> > nor derivation for test_util. That’s what I meant when I wrote “it
>> > seems awkward to be required to provide the test_util package as a
>> > separate crate”. Sorry if I accidently mislead you with this.
>>
>> Yes you’re right, this is probably awkard to maintain.
>>
>> Hum, i will retry. What’s motivating me to try this packaging way is
>> the duration of compilation… This fail only occur at the test phase,
>> so after 2 hours of compilation…
>>
>> When i use the “–keep-failed” option, and run a new build after fail
>> from the /tmp/guix-deno-xxx/ folder, everything finish well …
>>
>> So this is more a problem at frontier between this nested package and
>> “cargo-build-system” that don’t run some nested crate build.
>
> Did you *just* run a new build inside `/tmp/guix-deno-xxx/`? Or did you
> as well run a `cargo test` or similar command after it? Because I
> understand it is `cargo test` invoked by cargo-build-system that is
> failing[1].
>
>> I will revert my code to manage the deno compilation without test phase.
>> My objective is quarto, and i don’t know much about the next obstacle :)
>> I see later for this nested crate.
>
> Yup, it’s a sane approach.
>

No this is done i started Quarto packaging, i encouter some new difficulties … more in the bottom of mail …

>> >
>> >> How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?
>> >
>> > You don’t :)
>> >
>> > That’s the point of a functional package manager - there’s never need
>> > to *explicitly* reference files in the store. They are always referenced
>> > indirectly through packages, derivations, plain-file’s, gexps, etc. And
>> > they get created or reused automatically.
>> >
>>
>> So you directly say into the scm, passing this unique path `/gnu/store/xxxxx-deno-util-1-0-1’ to input function ??
>
> No no no.
>
> Let’s recall what you wanted to do in the first place
>
>> Another way is to first compile deno-test-util.scm, that install the
>> corresponding crate into /gnu/store, and after that i give this local
>> path to the inputs of my main rust-deno.scm . But i don’t know how to
>> give this path to my cargo build system input . How do you
>> reference/call/reuse a package that already exist in your /gnu/store
>> in a .scm file ?
>
> I’d say we already reached the decision that we don’t want to make
> rust-deno-test-util a distinct guix package. But for the sake of
> learning, let’s imagine that we do and that we want to reference its
> crate manually in another package recipe.
>
> Recall that you had the crate file at
> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/test_util-0.1.0.crate`.
> In the rust-deno recipe you were importing the record describing that
> crate’s package. It was being imported under the name
> `rust-deno-test-util-0.1.0`.
>
> So the `(arguments)` field of the recipe could contain sth like
>
>     #:phases
>     #~(modify-phases %standard-phases
>         (add-after ’build ’do-sth-with-test-util-crate
>           (lambda _
>             (do-something-with
>              #$(file-append rust-deno-test-util-0.1.0
>                             "/share/cargo/registry/test_util-0.1.0.crate")))))
>
> For simplicity I omitted other extra phases that you might put there.
> Notice that the phases are now computed using `#~` which is syntactic
> sugar for `(gexp)`. Also note that the crate file path gets introduced
> with `#$(file-append …)` where `#$` is syntactic sugar for `ungexp`.
> `(file-append)` itself as well as `#~` and `#$` become available when
> the `(guix gexp)` module is imported.
>
> This is a relatively low-level, gexp-based approach to using other
> packages during the build (and only the build). It probably looks like
> black magic now. To better understand it, please consult your copy of
> the “Guix black magic” handbook (aka the “G-Expressions” chapter of the
> GNU Guix manual[2]).

Yes, nice guix people give me some hint about that on Irc. I read the help page, i understand some of the examples,
but you well resumed my actual comprehension of the build process.

I miss a global view on the build process, and “why this is interesting/needed to use gexp at this point”. It seems this is a fact, so i try to use it without understanding all like often when you learn something :)

>
> If rust-deno-test-util was instead meant to be one of the `(inputs)`
> (i.e. if it was one of the runtime deps), we could instead use the
> following common idiom.
>
>     #:phases
>     `(modify-phases %standard-phases
>        (add-after ’build ’do-sth-with-test-util-crate
>          (lambda* (#:key inputs #:allow-other-keys)
>            (let ((test-util (assoc-ref inputs “rust-deno-test-util”)))
>              (do-something-with
>               (string-append test-util
>                              “/share/cargo/registry/test_util-0.1.0.crate”))))))
>
> Here I assumed that “rust-deno-test-util” is the name of the
> rust-deno-test-util Guix package and that this name is being
> automatically used as its key in the inputs association list. It is
> possible to explicitly assign different, non-default string keys to the
> packages listed among `(inputs)`. It is, however, not highly relevant
> now — let’s ignore this possibility.
>
> I already showed 2 ways of accessing a file produced by some
> prerequisite package/derivation. In both cases Guix shall automatically
> recognize that rust-deno-test-util is a prerequisite and build it if it
> is not yet present in `/gnu/store`. None of this approaches should be
> needed, however. That’s because in the case of cargo-build-system the standard
> way of providing crates is by listing the required crate packages among
> `#:cargo-inputs` or `#:cargo-development-inputs`. Just as you were
> doing. cargo-build-system then by itself takes care of collecting the
> crates inside the listed packages and instructing the `cargo` command
> to find those crates.
>

Thanks for theses explanation, i better understand how to access data from other derivation, that could help me for the next step.

> I don’t know what was still causing the error *after* you placed
> rust-deno-test-util among `#:cargo-development-inputs`. I guess the
> reason was specific to Deno build system and not to Guix nor to
> cargo-build-system.
>

About my progress on Quarto packaging, well, there are some interesting difficulties :)

• The Quarto main script (<https://github.com/quarto-dev/quarto-cli/blob/main/configure.sh>) try to download Deno binary, now that Deno is packaged, it’s easy to remove. I set `$QUARTO_VENDOR_BINARIES' to false, and set `$DENO_BIN' and `$QUARTO_DENO' env to the `/gnu/store/deno/bin'.

• Next step try to download `deno_std' : <https://github.com/quarto-dev/quarto-cli/blob/main/configure.sh#L79> . Quarto use `deno cache' capacity to propose some offline scripting capacity to user of Quarto. The command `deno cache' is run here : <https://github.com/quarto-dev/quarto-cli/blob/v1.1.251/package/scripts/deno_std/download.sh#L12>

The list of packaged downloaded by deno cache (`deno_std.ts'), with a corresponding lock file (`deno_std.lock'), is described here  : <https://github.com/quarto-dev/quarto-cli/blob/main/package/scripts/deno_std/deno_std.ts>

Because this is not possible to download thing during guix build packaging (that create a deno `.cache' folder into `/homeless-shelter' …. ), i search how nixer do that <https://discourse.nixos.org/t/packaging-deno-applications/15441/3>  . The good way to do that is to create something that reproduce the `deno cache' structure  : <https://stackoverflow.com/questions/61799309/where-can-i-see-deno-downloaded-packages>

By doing that, i could create a derivation that invoke a `deno cache' command to build a read-only `.cache' content described by `deno_std.ts' and give this folder (using `$DENO_DIR' variable ? <https://denolib.gitbook.io/guide/advanced/deno_dir-code-fetch-and-cache> ) to deno embedded / used by Quarto ? I also see there is possibility to set an `--importmap' command that use a command standard  <https://deno.land/manual@v1.14.2/npm_nodejs/import_maps> that is already used by quarto here (<https://github.com/quarto-dev/quarto-cli/blob/main/package/src/quarto-bld#L19>) and point to folder uri and not to http: uri (<https://github.com/quarto-dev/quarto-cli/blob/main/src/dev_import_map.json>)

I have no idea why there is two different way to manage these import, by caching (`deno cache') or directly by importing into `./vendor/'  using `--importmap'  folder … I’m not sure but there is the possibility to use `deno cache' + `--importmap' to solve this problem.

Anyway…. because i think this is not an *urgent feature* needed by common user of Quarto (<https://quarto.org/docs/projects/scripts.html>), i simply comment this line 79 to remove caching, in main configure script of Quarto.

• Next step is setting the `$DENO_DOM' variable needed by quarto command …

The repository is here, <https://github.com/b-fuze/deno-dom>, this is not a published crate … and a virtual-manifest … I discover new thing each day :(

The build phase run well but now i have problem with package and install phase, because this is a `virtual-manifest'
Packaging failed, this is not a problem, i removed it (using `install-source?'  flag) because i only need the `/bin' generated by build phase.

The actual trace of failed :

┌────
│    Compiling core v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/core)
│    Compiling plugin v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/plugin)
│     Finished release [optimized] target(s) in 24.74s
│ phase `build' succeeded after 24.8 seconds
│ starting phase `package'
│ Not installing cargo sources, skipping `cargo package`.
│ phase `package' succeeded after 0.0 seconds
│ starting phase `check'
│    Compiling core v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/core)
│    Compiling plugin v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/plugin)
│     Finished release [optimized] target(s) in 0.69s
│      Running unittests (target/release/deps/core-9e5a32d2886ce63b)
│ 
│ running 0 tests
│ 
│ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
│ 
│      Running unittests (target/release/deps/plugin-098ef3d813af0253)
│ 
│ running 0 tests
│ 
│ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
│ 
│    Doc-tests core
│ 
│ running 0 tests
│ 
│ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
│ 
│ phase `check' succeeded after 0.8 seconds
│ starting phase `install'
│ error: manifest path `/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/Cargo.toml` is a virtual manifest, but this command requires running against an actual package in this workspace
│ error: in phase 'install': uncaught exception:
│ json-error #<input: #{read pipe}# 14>
│ phase `install' failed after 0.0 seconds
│ Backtrace:
│           12 (primitive-load "/gnu/store/2f9fp1iyqdxsybnln8lb5j2q1jr…")
│ In guix/build/gnu-build-system.scm:
│     906:2 11 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
│ In ice-9/boot-9.scm:
│   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
│ In srfi/srfi-1.scm:
│     634:9  9 (for-each #<procedure 7ffff30020c0 at guix/build/gnu-b…> …)
│ In ice-9/boot-9.scm:
│   1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
│ In guix/build/gnu-build-system.scm:
│    927:23  7 (_)
│ In guix/build/cargo-build-system.scm:
│    242:13  6 (install #:inputs _ #:outputs _ #:skip-build? _ # _ # _)
│     58:19  5 (has-executable-target?)
│     48:15  4 (manifest-targets)
│ In guix/build/json.scm:
│    308:16  3 (read-json #<input: #{read pipe}# 14>)
│      32:2  2 (json-error #<input: #{read pipe}# 14>)
│ 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:
│ Throw to key `json-error' with args `(#<input: #{read pipe}# 14>)'.
│ builder for `/gnu/store/fsyrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv' failed with exit code 1
│ la compilation de /gnu/store/fsyrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv a échoué
│ Vous trouverez le journal de compilation dans « /var/log/guix/drvs/fs/yrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv.gz ».
│ guix build: erreur : build of `/gnu/store/fsyrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv' failed
│ 
└────

Looking to crate-io.scm and by doing some googling, i didn’t find an easy  way to manage the `install' phase when we encouter a `virtual-manifest' …   One way to do that is replacing `install' phases defined by `cargo-build-system' (<https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm>)

But this is an hard job for beginner like me… Perhaps there is another way by modifying this wtf `virtual manifest' directly.

┌────
│  (build-system cargo-build-system)
│      (arguments
│      `(#:skip-build? #f
│        #:install-source? #f     ; virtual manifest
│ ;       #:phases
│ ;       (modify-phases %standard-phases
│ ;        (replace 'install
│ ;         (lambda _
│ ;           #t)))
│            #:cargo-inputs
│            (("rust-html5ever" ,rust-html5ever-0.25.1)      ;;0.25.1
│              ("rust-markup5ever" ,rust-markup5ever-0.10.0)  ;0.10.0
│              ("rust-serde_json", rust-serde-json-1)            ;1.0
│              ("rust-serde", rust-serde-1)) ; 1.0.111
│            ))
└────

Well, long road never ends…

And ! an ! happy ! Christmas Hollidays ! for all of guixers !!

>> Thanks for your support and your kind word, that help me to continue :)
>
> Glad I could help even with my small Guix experience ^^
>
>> Hi,
>>
>> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
>>
>> ┌────
>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno –version
>> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
>> │ v8 10.6.194.5
>> │ typescript 4.7.4
>> │
>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
>> │ Hello John
>> │ Hello Sarah
>> │ Hello Kai
>> │
>> └────
>
> Great! 👏
>
>> Next steps :
>> • Packaging Quarto (that need Deno).
>> • Merge and Cleaning mess with dependency.
>
> Just a question, out of curiosity - are there any serious freedom
> issues? I saw you are using some custom Guix channels in addition to
> your own one and that made me wonder
>
> Wojtek
>
>
> [1] <https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/cargo-build-system.scm?id=408a4ed071c9c52de207d799a698781d49fa727d#n209>
> [2] <https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html>
>
> – (sig_start)
> website: <https://koszko.org/koszko.html>
> PGP: <https://koszko.org/key.gpg>
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>
> Meet Kraków saints!           #16: saint Jan z Dukli
> Poznaj świętych krakowskich!  #16: święty Jan z Dukli
> <https://pl.wikipedia.org/wiki/Jan_z_Dukli>
> – (sig_end)
>
>
> On Thu, 15 Dec 2022 09:32:48 +0100
> Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> wrote:
>
>> Hi,
>>
>> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
>>
>> ┌────
>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno –version
>> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
>> │ v8 10.6.194.5
>> │ typescript 4.7.4
>> │
>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
>> │ Hello John
>> │ Hello Sarah
>> │ Hello Kai
>> │
>> └────
>>
>> Next steps :
>> • Packaging Quarto (that need Deno).
>> • Merge and Cleaning mess with dependency.
>>
>> If you want to try :
>> <https://git.sr.ht/~reyman/build-deno-guix>
>>
>> Best regards,
>> SR
>>
>> “Sebastien Rey-Coyrehourcq” <sebastien.rey-coyrehourcq@univ-rouen.fr> writes:
>>
>> >
>> > Le Lundi, Octobre 24, 2022 13:43 CEST, Sébastien Rey-Coyrehourcq <sebastien.rey-coyrehourcq@univ-rouen.fr> a écrit:
>> >
>> >> Hi,
>> >>
>> >> I’m trying to package Quarto Cli (
>> >> <https://github.com/quarto-dev/quarto-cli> ), used in combination with
>> >> Pandoc to publish -reproducible- scientific document : website, blog, etc.
>> >>
>> >> I first think this is a classic gnu build : ./configure && make && make
>> >> install BUT, there is a problem because the ./configure script bootstrap
>> >> “Deno” during the run of configure.sh.
>> >>
>> >> Because this download and compilation of Deno occur during ./configure.sh
>> >> running, guix cannot patch the #!/bin/bash path, so ./configure failed.
>> >> Deno seems also not packaged into guix.
>> >>
>> >> Do you have an idea to resolve this ? Perhaps we could try all together to do this.
>> >>
>> >> I’m starting with this quarto-cli.scm :
>> >>
>> >> ┌────
>> >> │ (use-modules
>> >> │ (guix packages)
>> >> │ (guix download)
>> >> │ (guix build-system gnu)
>> >> │ (guix licenses)
>> >> │ )
>> >> │
>> >> │ (define-public quarto-cli
>> >> │   (package
>> >> │     (name “Quarto-CLI”)
>> >> │     (version “1.1.251”)
>> >> │     (source (origin
>> >> │               (method url-fetch)
>> >> │               (uri (string-append “<https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz>”))
>> >> │               (sha256
>> >> │                (base32
>> >> │                 “1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6”))))
>> >> │     (build-system gnu-build-system)
>> >> │     (synopsis “Quarto-cli”)
>> >> │     (description
>> >> │      “Quarto-cli description”)
>> >> │     (home-page “<https://github.com/quarto-dev/quarto-cli>”)
>> >> │     (license gpl3+)))
>> >> │ quarto-cli
>> >> │
>> >> └────
>> >>
>> >> To compile and fail :
>> >> guix build -f quarto-cli.scm
>> >>
>> >> Best,
>> >> Sebastien RC.
>> >
>> > Deno contain lot of packages dependencies actually,
>> > here i comment all packages not packaged in rust after a simple run of guix import …
>> >
>> > #+BEGIN_SRC scheme
>> >
>> > (use-modules
>> > (guix packages)
>> > (guix build-system cargo)
>> > (guix download)
>> > (guix licenses)
>> > (gnu packages rust)
>> > (gnu packages crates-io)
>> > )
>> >
>> > (define-public rust-deno-1
>> >   (package
>> >     (name “rust-deno”)
>> >     (version “1.26.2”)
>> >     (source (origin
>> >               (method url-fetch)
>> >               (uri (crate-uri “deno” version))
>> >               (file-name (string-append name “-” version “.tar.gz”))
>> >               (sha256
>> >                (base32
>> >                 “1yzvdkj8sq475kfbkms1lfysjddkfwcyqhp1ggalfbk4hqhbiz29”))))
>> >     (build-system cargo-build-system)
>> >     (arguments
>> >      `(#:cargo-inputs ((“rust-atty” ,rust-atty-0.2)
>> >                        (“rust-base64” ,rust-base64-0.13)
>> > ;                       (“rust-cache-control” ,rust-cache-control-0.2)
>> >                         (“rust-chrono” ,rust-chrono-0.4)
>> > ;                       (“rust-clap” ,rust-clap-3)
>> > ;                       (“rust-clap-complete” ,rust-clap-complete-3)
>> > ;                       (“rust-clap-complete-fig” ,rust-clap-complete-fig-3)
>> >                         (“rust-data-url” ,rust-data-url-0.1)
>> > ;                       (“rust-deno-ast” ,rust-deno-ast-0.19)
>> > ;                       (“rust-deno-broadcast-channel” ,rust-deno-broadcast-channel-0.67)
>> > ;                       (“rust-deno-cache” ,rust-deno-cache-0.5)
>> > ;                       (“rust-deno-console” ,rust-deno-console-0.73)
>> > ;                       (“rust-deno-core” ,rust-deno-core-0.155)
>> > ;                       (“rust-deno-core” ,rust-deno-core-0.155)
>> > ;                       (“rust-deno-crypto” ,rust-deno-crypto-0.87)
>> > ;                       (“rust-deno-doc” ,rust-deno-doc-0.46)
>> > ;                       (“rust-deno-emit” ,rust-deno-emit-0.9)
>> > ;                       (“rust-deno-fetch” ,rust-deno-fetch-0.96)
>> > ;                       (“rust-deno-graph” ,rust-deno-graph-0.34)
>> > ;                       (“rust-deno-lint” ,rust-deno-lint-0.33)
>> > ;                       (“rust-deno-net” ,rust-deno-net-0.65)
>> > ;                       (“rust-deno-node” ,rust-deno-node-0.10)
>> > ;                       (“rust-deno-runtime” ,rust-deno-runtime-0.81)
>> > ;                       (“rust-deno-task-shell” ,rust-deno-task-shell-0.5)
>> > ;                       (“rust-deno-url” ,rust-deno-url-0.73)
>> > ;                       (“rust-deno-web” ,rust-deno-web-0.104)
>> > ;                       (“rust-deno-webgpu” ,rust-deno-webgpu-0.74)
>> > ;                       (“rust-deno-websocket” ,rust-deno-websocket-0.78)
>> > ;                       (“rust-deno-webstorage” ,rust-deno-webstorage-0.68)
>> >                        (“rust-dissimilar” ,rust-dissimilar-1)
>> > ;                       (“rust-dprint-plugin-json” ,rust-dprint-plugin-json-0.15)
>> > ;                       (“rust-dprint-plugin-markdown” ,rust-dprint-plugin-markdown-0.14)
>> > ;                       (“rust-dprint-plugin-typescript” ,rust-dprint-plugin-typescript-0.74)
>> >                        (“rust-encoding-rs” ,rust-encoding-rs-0.8)
>> >                        (“rust-env-logger” ,rust-env-logger-0.9)
>> > ;                       (“rust-eszip” ,rust-eszip-0.28)
>> > ;                       (“rust-fancy-regex” ,rust-fancy-regex-0.10)
>> >                        (“rust-flate2” ,rust-flate2-1)
>> >                        (“rust-fwdansi” ,rust-fwdansi-1)
>> > ;                       (“rust-glibc-version” ,rust-glibc-version-0.1)
>> >                        (“rust-http” ,rust-http-0.2)
>> > ;                       (“rust-import-map” ,rust-import-map-0.12)
>> >                        (“rust-indexmap” ,rust-indexmap-1)
>> > ;                       (“rust-indicatif” ,rust-indicatif-0.17)
>> > ;                       (“rust-jsonc-parser” ,rust-jsonc-parser-0.21)
>> > ;                       (“rust-junction” ,rust-junction-0.2)
>> >                        (“rust-libc” ,rust-libc-0.2)
>> >                        (“rust-log” ,rust-log-0.4)
>> > ;                       (“rust-mitata” ,rust-mitata-0.0.7)
>> > ;                       (“rust-monch” ,rust-monch-0.2)
>> > ;                       (“rust-napi-sym” ,rust-napi-sym-0.3)
>> >                        (“rust-notify” ,rust-notify-5)
>> >                        (“rust-once-cell” ,rust-once-cell-1)
>> >                        (“rust-os-pipe” ,rust-os-pipe-1)
>> >                        (“rust-percent-encoding” ,rust-percent-encoding-2)
>> >                        (“rust-pin-project” ,rust-pin-project-1)
>> >                        (“rust-rand” ,rust-rand-0.8)
>> >                        (“rust-regex” ,rust-regex-1)
>> >                        (“rust-regex” ,rust-regex-1)
>> >                        (“rust-ring” ,rust-ring-0.16)
>> > ;                       (“rust-rustyline” ,rust-rustyline-10)
>> > ;                       (“rust-rustyline-derive” ,rust-rustyline-derive-0.7)
>> >                        (“rust-semver” ,rust-semver-1)
>> >                        (“rust-serde” ,rust-serde-1)
>> >                        (“rust-serde” ,rust-serde-1)
>> >                        (“rust-serde-json” ,rust-serde-json-1)
>> >                        (“rust-serde-repr” ,rust-serde-repr-0.1)
>> >                        (“rust-shell-escape” ,rust-shell-escape-0.1)
>> >                        (“rust-tar” ,rust-tar-0.4)
>> >                        (“rust-tempfile” ,rust-tempfile-3)
>> >                        (“rust-text-size” ,rust-text-size-1)
>> > ;                       (“rust-text-lines” ,rust-text-lines-0.6)
>> >                        (“rust-tokio” ,rust-tokio-1)
>> > ;                       (“rust-tokio-util” ,rust-tokio-util-0.7)
>> > ;                       (“rust-tower-lsp” ,rust-tower-lsp-0.17)
>> >                        (“rust-twox-hash” ,rust-twox-hash-1)
>> >                        (“rust-typed-arena” ,rust-typed-arena-2)
>> > ;                       (“rust-uuid” ,rust-uuid-1)
>> >                        (“rust-walkdir” ,rust-walkdir-2)
>> >                        (“rust-winapi” ,rust-winapi-0.3)
>> >                        (“rust-winapi” ,rust-winapi-0.3)
>> >                        (“rust-winres” ,rust-winres-0.1)
>> > ;                      (“rust-zstd” ,rust-zstd-0.11)
>> >                        )
>> >        #:cargo-development-inputs (
>> >                                    ;(“rust-deno-bench-util” ,rust-deno-bench-util-0.67)
>> >                                    (“rust-dotenv” ,rust-dotenv-0.15)
>> >                                    ;(“rust-flaky-test” ,rust-flaky-test-0.1)
>> >                                    ;(“rust-nix” ,rust-nix-0.24)
>> >                                    (“rust-once-cell” ,rust-once-cell-1)
>> >                                    (“rust-os-pipe” ,rust-os-pipe-1)
>> >                                    (“rust-pretty-assertions” ,rust-pretty-assertions-1)
>> >                                    ;(“rust-trust-dns-client” ,rust-trust-dns-client-0.22)
>> >                                    ;(“rust-trust-dns-server” ,rust-trust-dns-server-0.22))))
>> >     (home-page “<https://github.com/denoland/deno>”)
>> >     (synopsis “Provides the deno executable”)
>> >     (description “This package provides the deno executable”)
>> >     (license expat)))
>> >
>> > rust-deno-1
>> >
>> > #+END_SRC
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 889 bytes --]

Re: Help packaging R Quarto Cli

[Rey-Coyrehourcq Sébastien]

Hi,

Some news about *Quarto* Packaging :

# Deno [Done]

- the first big/huge dependency of Quarto is Deno, packaged in december 
: Deno (https://deno.land/)

# Deno-Dom [Done]

The problem of deno_dom plugin of deno 
(https://github.com/b-fuze/deno-dom), provided as a rust virtual 
manifest is also solved, i only need to specify this to .scm :

  -  #skip-build? to false,
  -  #:cargo-test-flag to --release
  - #:install-source? to false
  - replace `install phase of rust by a new that only copy libplugin.so 
file into /bin

# Sass css preprocessor [Done]

Quarto need also the sass executable to compile .scss into .css.

Sass is written in Dart, but by change there is a js executable 
available in NPM Registry. I set a module to download sass (and 3 other 
dependencies) from npm registry,
and by deleting configure and install phase, everything goes well. I 
create a new channel with this dependencies.

# ESBuild [Done]

EsBuild is available in Guix by luck.

# Quarto

Quarto is available to compile on github, defined as a dev version.

## Configure.sh

The entry for this dev version is an horrible (from the guix point of 
view) ./configure.sh 
(https://github.com/quarto-dev/quarto-cli/blob/main/configure.sh) , that 
download binary of deno, pandoc, and other things.

I first patch this configure and set correctly all the environnement 
variable correctly (Deno, Pandoc, ESbuild, Sass, Node, etc.).

And now i thing this is probably the last pitfall ? before the end of 
this challenge...

## Packaging Quarto

After running ./configure.sh i get the next step from conda recipe 
(https://github.com/quarto-dev/quarto-cli/tree/main/package/conda-recipe/build.sh).

Conda recipe generate a standalone bundle (a ./quarto (sh) and a 
./quarto.js) by using this shell script : 
https://github.com/quarto-dev/quarto-cli/blob/main/package/src/quarto-bld

As you could see in the code, quarto-bld run Deno with some options, one 
refer to some .json, that contain lot of thing to download into 
/vendors. But it seems this part is not activated if the 
QUARTO_VENDOR_BINARIES env is set to false.

(A) / quarto-bld update-html-dependencies
(B) / quarto-bld prepare-dist

The A step call this thing 
(https://github.com/quarto-dev/quarto-cli/blob/main/package/src/common/update-html-dependencies.ts) 
that download and patch some file into the project.

So, A is a problem, and i need to patch this typescript file to give 
directly the file without downloading it from internet.

*How could i create an archive that contain already these different 
files to my quarto build ? *

*Do you think building a git repo with all of them is a good idea ?* 
Even if these files are linked to multiple sources : https://unpkg.com/; 
https://github.com/ ; 
https://github.com/mozilla/pdf.js/releases/download/ ; 
https://github.com/twbs/icons/releases/download/

If i download these file by running manually (A) in /tmp after a fail 
build, the (B) command build a working "./quarto --help" and "./quarto 
check" command, so end is near \o/

## Running

Quarto entry is a shell script with lot of environments variables, so we 
probably need to wrap it to run correctly.

Thanks again,

Best regards.









On 22/12/2022 16:16, Sébastien Rey-Coyrehourcq wrote:
> Hi,
>
> Wojtek Kosior<koszko@koszko.org>  writes:
>
>
>>>>> I found only one crate that use this method `git-fetch’ in the list :
>>>>> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/crates-io.scm#n1576>
>>>> There are plenty in other package definition files, e.g. in
>>>> gnu/packages/python-xyz.scm. It seems Rust is just that special case
>>>> where git checkout is rarely needed.
>>> Yes,  i’m not sure this case (source only without crate) is well managed by the actual cargo-build-system ?
>>> Anyway, discussions about “Rust Packaging” on IRC mention the building of a new system, something cargo-less.
>> What do you mean by “source only without crate”? From my understanding,
>> even when we use `(method uri-fetch)` with `(crate-uri)`, what gets
>> downloaded is still just the source code and not a prebuilt crate. The
>> crates repo serves both the crates and their corresponding source
>> tarballs, right?
>>
>> Even though there is a difference from the `(method git-fetch)` case —
>> the output is a tarball instead of a directory — it’s still just source
>> code and the untaring of it is — I believe — done automatically.
>>
>> Or it is something else you meant?
>>
> Yes, you’re right.
>
>>>> I wanted to instead suggest not creating a separate Guix package
>>>> nor derivation for test_util. That’s what I meant when I wrote “it
>>>> seems awkward to be required to provide the test_util package as a
>>>> separate crate”. Sorry if I accidently mislead you with this.
>>> Yes you’re right, this is probably awkard to maintain.
>>>
>>> Hum, i will retry. What’s motivating me to try this packaging way is
>>> the duration of compilation… This fail only occur at the test phase,
>>> so after 2 hours of compilation…
>>>
>>> When i use the “–keep-failed” option, and run a new build after fail
>>> from the /tmp/guix-deno-xxx/ folder, everything finish well …
>>>
>>> So this is more a problem at frontier between this nested package and
>>> “cargo-build-system” that don’t run some nested crate build.
>> Did you *just* run a new build inside `/tmp/guix-deno-xxx/`? Or did you
>> as well run a `cargo test` or similar command after it? Because I
>> understand it is `cargo test` invoked by cargo-build-system that is
>> failing[1].
>>
>>> I will revert my code to manage the deno compilation without test phase.
>>> My objective is quarto, and i don’t know much about the next obstacle :)
>>> I see later for this nested crate.
>> Yup, it’s a sane approach.
>>
> No this is done i started Quarto packaging, i encouter some new difficulties … more in the bottom of mail …
>
>>>>> How do you reference/call/reuse a package that already exist in your /gnu/store in a .scm file ?
>>>> You don’t :)
>>>>
>>>> That’s the point of a functional package manager - there’s never need
>>>> to *explicitly* reference files in the store. They are always referenced
>>>> indirectly through packages, derivations, plain-file’s, gexps, etc. And
>>>> they get created or reused automatically.
>>>>
>>> So you directly say into the scm, passing this unique path `/gnu/store/xxxxx-deno-util-1-0-1’ to input function ??
>> No no no.
>>
>> Let’s recall what you wanted to do in the first place
>>
>>> Another way is to first compile deno-test-util.scm, that install the
>>> corresponding crate into /gnu/store, and after that i give this local
>>> path to the inputs of my main rust-deno.scm . But i don’t know how to
>>> give this path to my cargo build system input . How do you
>>> reference/call/reuse a package that already exist in your /gnu/store
>>> in a .scm file ?
>> I’d say we already reached the decision that we don’t want to make
>> rust-deno-test-util a distinct guix package. But for the sake of
>> learning, let’s imagine that we do and that we want to reference its
>> crate manually in another package recipe.
>>
>> Recall that you had the crate file at
>> `/gnu/store/ma04jfp0f33kf38cdn66qai60nhqxx7d-rust-deno-test-util-0.1.0/share/cargo/registry/test_util-0.1.0.crate`.
>> In the rust-deno recipe you were importing the record describing that
>> crate’s package. It was being imported under the name
>> `rust-deno-test-util-0.1.0`.
>>
>> So the `(arguments)` field of the recipe could contain sth like
>>
>>      #:phases
>>      #~(modify-phases %standard-phases
>>          (add-after ’build ’do-sth-with-test-util-crate
>>            (lambda _
>>              (do-something-with
>>               #$(file-append rust-deno-test-util-0.1.0
>>                              "/share/cargo/registry/test_util-0.1.0.crate")))))
>>
>> For simplicity I omitted other extra phases that you might put there.
>> Notice that the phases are now computed using `#~` which is syntactic
>> sugar for `(gexp)`. Also note that the crate file path gets introduced
>> with `#$(file-append …)` where `#$` is syntactic sugar for `ungexp`.
>> `(file-append)` itself as well as `#~` and `#$` become available when
>> the `(guix gexp)` module is imported.
>>
>> This is a relatively low-level, gexp-based approach to using other
>> packages during the build (and only the build). It probably looks like
>> black magic now. To better understand it, please consult your copy of
>> the “Guix black magic” handbook (aka the “G-Expressions” chapter of the
>> GNU Guix manual[2]).
> Yes, nice guix people give me some hint about that on Irc. I read the help page, i understand some of the examples,
> but you well resumed my actual comprehension of the build process.
>
> I miss a global view on the build process, and “why this is interesting/needed to use gexp at this point”. It seems this is a fact, so i try to use it without understanding all like often when you learn something :)
>
>> If rust-deno-test-util was instead meant to be one of the `(inputs)`
>> (i.e. if it was one of the runtime deps), we could instead use the
>> following common idiom.
>>
>>      #:phases
>>      `(modify-phases %standard-phases
>>         (add-after ’build ’do-sth-with-test-util-crate
>>           (lambda* (#:key inputs #:allow-other-keys)
>>             (let ((test-util (assoc-ref inputs “rust-deno-test-util”)))
>>               (do-something-with
>>                (string-append test-util
>>                               “/share/cargo/registry/test_util-0.1.0.crate”))))))
>>
>> Here I assumed that “rust-deno-test-util” is the name of the
>> rust-deno-test-util Guix package and that this name is being
>> automatically used as its key in the inputs association list. It is
>> possible to explicitly assign different, non-default string keys to the
>> packages listed among `(inputs)`. It is, however, not highly relevant
>> now — let’s ignore this possibility.
>>
>> I already showed 2 ways of accessing a file produced by some
>> prerequisite package/derivation. In both cases Guix shall automatically
>> recognize that rust-deno-test-util is a prerequisite and build it if it
>> is not yet present in `/gnu/store`. None of this approaches should be
>> needed, however. That’s because in the case of cargo-build-system the standard
>> way of providing crates is by listing the required crate packages among
>> `#:cargo-inputs` or `#:cargo-development-inputs`. Just as you were
>> doing. cargo-build-system then by itself takes care of collecting the
>> crates inside the listed packages and instructing the `cargo` command
>> to find those crates.
>>
> Thanks for theses explanation, i better understand how to access data from other derivation, that could help me for the next step.
>
>> I don’t know what was still causing the error *after* you placed
>> rust-deno-test-util among `#:cargo-development-inputs`. I guess the
>> reason was specific to Deno build system and not to Guix nor to
>> cargo-build-system.
>>
> About my progress on Quarto packaging, well, there are some interesting difficulties :)
>
> • The Quarto main script (<https://github.com/quarto-dev/quarto-cli/blob/main/configure.sh>) try to download Deno binary, now that Deno is packaged, it’s easy to remove. I set `$QUARTO_VENDOR_BINARIES' to false, and set `$DENO_BIN' and `$QUARTO_DENO' env to the `/gnu/store/deno/bin'.
>
> • Next step try to download `deno_std' :<https://github.com/quarto-dev/quarto-cli/blob/main/configure.sh#L79>  . Quarto use `deno cache' capacity to propose some offline scripting capacity to user of Quarto. The command `deno cache' is run here :<https://github.com/quarto-dev/quarto-cli/blob/v1.1.251/package/scripts/deno_std/download.sh#L12>
>
> The list of packaged downloaded by deno cache (`deno_std.ts'), with a corresponding lock file (`deno_std.lock'), is described here  :<https://github.com/quarto-dev/quarto-cli/blob/main/package/scripts/deno_std/deno_std.ts>
>
> Because this is not possible to download thing during guix build packaging (that create a deno `.cache' folder into `/homeless-shelter' …. ), i search how nixer do that<https://discourse.nixos.org/t/packaging-deno-applications/15441/3>   . The good way to do that is to create something that reproduce the `deno cache' structure  :<https://stackoverflow.com/questions/61799309/where-can-i-see-deno-downloaded-packages>
>
> By doing that, i could create a derivation that invoke a `deno cache' command to build a read-only `.cache' content described by `deno_std.ts' and give this folder (using `$DENO_DIR' variable ?<https://denolib.gitbook.io/guide/advanced/deno_dir-code-fetch-and-cache>  ) to deno embedded / used by Quarto ? I also see there is possibility to set an `--importmap' command that use a command standard<https://deno.land/manual@v1.14.2/npm_nodejs/import_maps>  that is already used by quarto here (<https://github.com/quarto-dev/quarto-cli/blob/main/package/src/quarto-bld#L19>) and point to folder uri and not to http: uri (<https://github.com/quarto-dev/quarto-cli/blob/main/src/dev_import_map.json>)
>
> I have no idea why there is two different way to manage these import, by caching (`deno cache') or directly by importing into `./vendor/'  using `--importmap'  folder … I’m not sure but there is the possibility to use `deno cache' + `--importmap' to solve this problem.
>
> Anyway…. because i think this is not an *urgent feature* needed by common user of Quarto (<https://quarto.org/docs/projects/scripts.html>), i simply comment this line 79 to remove caching, in main configure script of Quarto.
>
> • Next step is setting the `$DENO_DOM' variable needed by quarto command …
>
> The repository is here,<https://github.com/b-fuze/deno-dom>, this is not a published crate … and a virtual-manifest … I discover new thing each day :(
>
> The build phase run well but now i have problem with package and install phase, because this is a `virtual-manifest'
> Packaging failed, this is not a problem, i removed it (using `install-source?'  flag) because i only need the `/bin' generated by build phase.
>
> The actual trace of failed :
>
> ┌────
> │    Compiling core v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/core)
> │    Compiling plugin v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/plugin)
> │     Finished release [optimized] target(s) in 24.74s
> │ phase `build' succeeded after 24.8 seconds
> │ starting phase `package'
> │ Not installing cargo sources, skipping `cargo package`.
> │ phase `package' succeeded after 0.0 seconds
> │ starting phase `check'
> │    Compiling core v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/core)
> │    Compiling plugin v0.1.0 (/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/html-parser/plugin)
> │     Finished release [optimized] target(s) in 0.69s
> │      Running unittests (target/release/deps/core-9e5a32d2886ce63b)
> │
> │ running 0 tests
> │
> │ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
> │
> │      Running unittests (target/release/deps/plugin-098ef3d813af0253)
> │
> │ running 0 tests
> │
> │ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
> │
> │    Doc-tests core
> │
> │ running 0 tests
> │
> │ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
> │
> │ phase `check' succeeded after 0.8 seconds
> │ starting phase `install'
> │ error: manifest path `/tmp/guix-build-rust-deno-test-util-0.1.17-alpha.drv-0/source/Cargo.toml` is a virtual manifest, but this command requires running against an actual package in this workspace
> │ error: in phase 'install': uncaught exception:
> │ json-error #<input: #{read pipe}# 14>
> │ phase `install' failed after 0.0 seconds
> │ Backtrace:
> │           12 (primitive-load "/gnu/store/2f9fp1iyqdxsybnln8lb5j2q1jr…")
> │ In guix/build/gnu-build-system.scm:
> │     906:2 11 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> │ In ice-9/boot-9.scm:
> │   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> │ In srfi/srfi-1.scm:
> │     634:9  9 (for-each #<procedure 7ffff30020c0 at guix/build/gnu-b…> …)
> │ In ice-9/boot-9.scm:
> │   1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
> │ In guix/build/gnu-build-system.scm:
> │    927:23  7 (_)
> │ In guix/build/cargo-build-system.scm:
> │    242:13  6 (install #:inputs _ #:outputs _ #:skip-build? _ # _ # _)
> │     58:19  5 (has-executable-target?)
> │     48:15  4 (manifest-targets)
> │ In guix/build/json.scm:
> │    308:16  3 (read-json #<input: #{read pipe}# 14>)
> │      32:2  2 (json-error #<input: #{read pipe}# 14>)
> │ 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:
> │ Throw to key `json-error' with args `(#<input: #{read pipe}# 14>)'.
> │ builder for `/gnu/store/fsyrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv' failed with exit code 1
> │ la compilation de /gnu/store/fsyrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv a échoué
> │ Vous trouverez le journal de compilation dans « /var/log/guix/drvs/fs/yrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv.gz ».
> │ guix build: erreur : build of `/gnu/store/fsyrsm3wx60zjkcghx8inmfw3y6y8am8-rust-deno-test-util-0.1.17-alpha.drv' failed
> │
> └────
>
> Looking to crate-io.scm and by doing some googling, i didn’t find an easy  way to manage the `install' phase when we encouter a `virtual-manifest' …   One way to do that is replacing `install' phases defined by `cargo-build-system' (<https://github.com/ecbrown/guix/blob/master/guix/build/cargo-build-system.scm>)
>
> But this is an hard job for beginner like me… Perhaps there is another way by modifying this wtf `virtual manifest' directly.
>
> ┌────
> │  (build-system cargo-build-system)
> │      (arguments
> │      `(#:skip-build? #f
> │        #:install-source? #f     ; virtual manifest
> │ ;       #:phases
> │ ;       (modify-phases %standard-phases
> │ ;        (replace 'install
> │ ;         (lambda _
> │ ;           #t)))
> │            #:cargo-inputs
> │            (("rust-html5ever" ,rust-html5ever-0.25.1)      ;;0.25.1
> │              ("rust-markup5ever" ,rust-markup5ever-0.10.0)  ;0.10.0
> │              ("rust-serde_json", rust-serde-json-1)            ;1.0
> │              ("rust-serde", rust-serde-1)) ; 1.0.111
> │            ))
> └────
>
> Well, long road never ends…
>
> And ! an ! happy ! Christmas Hollidays ! for all of guixers !!
>
>>> Thanks for your support and your kind word, that help me to continue :)
>> Glad I could help even with my small Guix experience ^^
>>
>>> Hi,
>>>
>>> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
>>>
>>> ┌────
>>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno –version
>>> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
>>> │ v8 10.6.194.5
>>> │ typescript 4.7.4
>>> │
>>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
>>> │ Hello John
>>> │ Hello Sarah
>>> │ Hello Kai
>>> │
>>> └────
>> Great! 👏
>>
>>> Next steps :
>>> • Packaging Quarto (that need Deno).
>>> • Merge and Cleaning mess with dependency.
>> Just a question, out of curiosity - are there any serious freedom
>> issues? I saw you are using some custom Guix channels in addition to
>> your own one and that made me wonder
>>
>> Wojtek
>>
>>
>> [1]<https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/cargo-build-system.scm?id=408a4ed071c9c52de207d799a698781d49fa727d#n209>
>> [2]<https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html>
>>
>> – (sig_start)
>> website:<https://koszko.org/koszko.html>
>> PGP:<https://koszko.org/key.gpg>
>> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
>>
>> Meet Kraków saints!           #16: saint Jan z Dukli
>> Poznaj świętych krakowskich!  #16: święty Jan z Dukli
>> <https://pl.wikipedia.org/wiki/Jan_z_Dukli>
>> – (sig_end)
>>
>>
>> On Thu, 15 Dec 2022 09:32:48 +0100
>> Sébastien Rey-Coyrehourcq<sebastien.rey-coyrehourcq@univ-rouen.fr>  wrote:
>>
>>> Hi,
>>>
>>> I’m happy to say, Deno is packaged (except the test, see the last conversion on this thread) compile and run on my machine :D
>>>
>>> ┌────
>>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno –version
>>> │ deno 1.25.2 (release, x86_64-unknown-linux-gnu)
>>> │ v8 10.6.194.5
>>> │ typescript 4.7.4
>>> │
>>> │ /-> /gnu/store/xvjymz07g2dy112cz4x6pz7v4q8p7c6a-rust-deno-1.25.2/bin/deno run hello-world.js
>>> │ Hello John
>>> │ Hello Sarah
>>> │ Hello Kai
>>> │
>>> └────
>>>
>>> Next steps :
>>> • Packaging Quarto (that need Deno).
>>> • Merge and Cleaning mess with dependency.
>>>
>>> If you want to try :
>>> <https://git.sr.ht/~reyman/build-deno-guix>
>>>
>>> Best regards,
>>> SR
>>>
>>> “Sebastien Rey-Coyrehourcq”<sebastien.rey-coyrehourcq@univ-rouen.fr>  writes:
>>>
>>>> Le Lundi, Octobre 24, 2022 13:43 CEST, Sébastien Rey-Coyrehourcq<sebastien.rey-coyrehourcq@univ-rouen.fr>  a écrit:
>>>>
>>>>> Hi,
>>>>>
>>>>> I’m trying to package Quarto Cli (
>>>>> <https://github.com/quarto-dev/quarto-cli>  ), used in combination with
>>>>> Pandoc to publish -reproducible- scientific document : website, blog, etc.
>>>>>
>>>>> I first think this is a classic gnu build : ./configure && make && make
>>>>> install BUT, there is a problem because the ./configure script bootstrap
>>>>> “Deno” during the run of configure.sh.
>>>>>
>>>>> Because this download and compilation of Deno occur during ./configure.sh
>>>>> running, guix cannot patch the #!/bin/bash path, so ./configure failed.
>>>>> Deno seems also not packaged into guix.
>>>>>
>>>>> Do you have an idea to resolve this ? Perhaps we could try all together to do this.
>>>>>
>>>>> I’m starting with this quarto-cli.scm :
>>>>>
>>>>> ┌────
>>>>> │ (use-modules
>>>>> │ (guix packages)
>>>>> │ (guix download)
>>>>> │ (guix build-system gnu)
>>>>> │ (guix licenses)
>>>>> │ )
>>>>> │
>>>>> │ (define-public quarto-cli
>>>>> │   (package
>>>>> │     (name “Quarto-CLI”)
>>>>> │     (version “1.1.251”)
>>>>> │     (source (origin
>>>>> │               (method url-fetch)
>>>>> │               (uri (string-append “<https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz>”))
>>>>> │               (sha256
>>>>> │                (base32
>>>>> │                 “1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6”))))
>>>>> │     (build-system gnu-build-system)
>>>>> │     (synopsis “Quarto-cli”)
>>>>> │     (description
>>>>> │      “Quarto-cli description”)
>>>>> │     (home-page “<https://github.com/quarto-dev/quarto-cli>”)
>>>>> │     (license gpl3+)))
>>>>> │ quarto-cli
>>>>> │
>>>>> └────
>>>>>
>>>>> To compile and fail :
>>>>> guix build -f quarto-cli.scm
>>>>>
>>>>> Best,
>>>>> Sebastien RC.
>>>> Deno contain lot of packages dependencies actually,
>>>> here i comment all packages not packaged in rust after a simple run of guix import …
>>>>
>>>> #+BEGIN_SRC scheme
>>>>
>>>> (use-modules
>>>> (guix packages)
>>>> (guix build-system cargo)
>>>> (guix download)
>>>> (guix licenses)
>>>> (gnu packages rust)
>>>> (gnu packages crates-io)
>>>> )
>>>>
>>>> (define-public rust-deno-1
>>>>    (package
>>>>      (name “rust-deno”)
>>>>      (version “1.26.2”)
>>>>      (source (origin
>>>>                (method url-fetch)
>>>>                (uri (crate-uri “deno” version))
>>>>                (file-name (string-append name “-” version “.tar.gz”))
>>>>                (sha256
>>>>                 (base32
>>>>                  “1yzvdkj8sq475kfbkms1lfysjddkfwcyqhp1ggalfbk4hqhbiz29”))))
>>>>      (build-system cargo-build-system)
>>>>      (arguments
>>>>       `(#:cargo-inputs ((“rust-atty” ,rust-atty-0.2)
>>>>                         (“rust-base64” ,rust-base64-0.13)
>>>> ;                       (“rust-cache-control” ,rust-cache-control-0.2)
>>>>                          (“rust-chrono” ,rust-chrono-0.4)
>>>> ;                       (“rust-clap” ,rust-clap-3)
>>>> ;                       (“rust-clap-complete” ,rust-clap-complete-3)
>>>> ;                       (“rust-clap-complete-fig” ,rust-clap-complete-fig-3)
>>>>                          (“rust-data-url” ,rust-data-url-0.1)
>>>> ;                       (“rust-deno-ast” ,rust-deno-ast-0.19)
>>>> ;                       (“rust-deno-broadcast-channel” ,rust-deno-broadcast-channel-0.67)
>>>> ;                       (“rust-deno-cache” ,rust-deno-cache-0.5)
>>>> ;                       (“rust-deno-console” ,rust-deno-console-0.73)
>>>> ;                       (“rust-deno-core” ,rust-deno-core-0.155)
>>>> ;                       (“rust-deno-core” ,rust-deno-core-0.155)
>>>> ;                       (“rust-deno-crypto” ,rust-deno-crypto-0.87)
>>>> ;                       (“rust-deno-doc” ,rust-deno-doc-0.46)
>>>> ;                       (“rust-deno-emit” ,rust-deno-emit-0.9)
>>>> ;                       (“rust-deno-fetch” ,rust-deno-fetch-0.96)
>>>> ;                       (“rust-deno-graph” ,rust-deno-graph-0.34)
>>>> ;                       (“rust-deno-lint” ,rust-deno-lint-0.33)
>>>> ;                       (“rust-deno-net” ,rust-deno-net-0.65)
>>>> ;                       (“rust-deno-node” ,rust-deno-node-0.10)
>>>> ;                       (“rust-deno-runtime” ,rust-deno-runtime-0.81)
>>>> ;                       (“rust-deno-task-shell” ,rust-deno-task-shell-0.5)
>>>> ;                       (“rust-deno-url” ,rust-deno-url-0.73)
>>>> ;                       (“rust-deno-web” ,rust-deno-web-0.104)
>>>> ;                       (“rust-deno-webgpu” ,rust-deno-webgpu-0.74)
>>>> ;                       (“rust-deno-websocket” ,rust-deno-websocket-0.78)
>>>> ;                       (“rust-deno-webstorage” ,rust-deno-webstorage-0.68)
>>>>                         (“rust-dissimilar” ,rust-dissimilar-1)
>>>> ;                       (“rust-dprint-plugin-json” ,rust-dprint-plugin-json-0.15)
>>>> ;                       (“rust-dprint-plugin-markdown” ,rust-dprint-plugin-markdown-0.14)
>>>> ;                       (“rust-dprint-plugin-typescript” ,rust-dprint-plugin-typescript-0.74)
>>>>                         (“rust-encoding-rs” ,rust-encoding-rs-0.8)
>>>>                         (“rust-env-logger” ,rust-env-logger-0.9)
>>>> ;                       (“rust-eszip” ,rust-eszip-0.28)
>>>> ;                       (“rust-fancy-regex” ,rust-fancy-regex-0.10)
>>>>                         (“rust-flate2” ,rust-flate2-1)
>>>>                         (“rust-fwdansi” ,rust-fwdansi-1)
>>>> ;                       (“rust-glibc-version” ,rust-glibc-version-0.1)
>>>>                         (“rust-http” ,rust-http-0.2)
>>>> ;                       (“rust-import-map” ,rust-import-map-0.12)
>>>>                         (“rust-indexmap” ,rust-indexmap-1)
>>>> ;                       (“rust-indicatif” ,rust-indicatif-0.17)
>>>> ;                       (“rust-jsonc-parser” ,rust-jsonc-parser-0.21)
>>>> ;                       (“rust-junction” ,rust-junction-0.2)
>>>>                         (“rust-libc” ,rust-libc-0.2)
>>>>                         (“rust-log” ,rust-log-0.4)
>>>> ;                       (“rust-mitata” ,rust-mitata-0.0.7)
>>>> ;                       (“rust-monch” ,rust-monch-0.2)
>>>> ;                       (“rust-napi-sym” ,rust-napi-sym-0.3)
>>>>                         (“rust-notify” ,rust-notify-5)
>>>>                         (“rust-once-cell” ,rust-once-cell-1)
>>>>                         (“rust-os-pipe” ,rust-os-pipe-1)
>>>>                         (“rust-percent-encoding” ,rust-percent-encoding-2)
>>>>                         (“rust-pin-project” ,rust-pin-project-1)
>>>>                         (“rust-rand” ,rust-rand-0.8)
>>>>                         (“rust-regex” ,rust-regex-1)
>>>>                         (“rust-regex” ,rust-regex-1)
>>>>                         (“rust-ring” ,rust-ring-0.16)
>>>> ;                       (“rust-rustyline” ,rust-rustyline-10)
>>>> ;                       (“rust-rustyline-derive” ,rust-rustyline-derive-0.7)
>>>>                         (“rust-semver” ,rust-semver-1)
>>>>                         (“rust-serde” ,rust-serde-1)
>>>>                         (“rust-serde” ,rust-serde-1)
>>>>                         (“rust-serde-json” ,rust-serde-json-1)
>>>>                         (“rust-serde-repr” ,rust-serde-repr-0.1)
>>>>                         (“rust-shell-escape” ,rust-shell-escape-0.1)
>>>>                         (“rust-tar” ,rust-tar-0.4)
>>>>                         (“rust-tempfile” ,rust-tempfile-3)
>>>>                         (“rust-text-size” ,rust-text-size-1)
>>>> ;                       (“rust-text-lines” ,rust-text-lines-0.6)
>>>>                         (“rust-tokio” ,rust-tokio-1)
>>>> ;                       (“rust-tokio-util” ,rust-tokio-util-0.7)
>>>> ;                       (“rust-tower-lsp” ,rust-tower-lsp-0.17)
>>>>                         (“rust-twox-hash” ,rust-twox-hash-1)
>>>>                         (“rust-typed-arena” ,rust-typed-arena-2)
>>>> ;                       (“rust-uuid” ,rust-uuid-1)
>>>>                         (“rust-walkdir” ,rust-walkdir-2)
>>>>                         (“rust-winapi” ,rust-winapi-0.3)
>>>>                         (“rust-winapi” ,rust-winapi-0.3)
>>>>                         (“rust-winres” ,rust-winres-0.1)
>>>> ;                      (“rust-zstd” ,rust-zstd-0.11)
>>>>                         )
>>>>         #:cargo-development-inputs (
>>>>                                     ;(“rust-deno-bench-util” ,rust-deno-bench-util-0.67)
>>>>                                     (“rust-dotenv” ,rust-dotenv-0.15)
>>>>                                     ;(“rust-flaky-test” ,rust-flaky-test-0.1)
>>>>                                     ;(“rust-nix” ,rust-nix-0.24)
>>>>                                     (“rust-once-cell” ,rust-once-cell-1)
>>>>                                     (“rust-os-pipe” ,rust-os-pipe-1)
>>>>                                     (“rust-pretty-assertions” ,rust-pretty-assertions-1)
>>>>                                     ;(“rust-trust-dns-client” ,rust-trust-dns-client-0.22)
>>>>                                     ;(“rust-trust-dns-server” ,rust-trust-dns-server-0.22))))
>>>>      (home-page “<https://github.com/denoland/deno>”)
>>>>      (synopsis “Provides the deno executable”)
>>>>      (description “This package provides the deno executable”)
>>>>      (license expat)))
>>>>
>>>> rust-deno-1
>>>>
>>>> #+END_SRC
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>

Re: Help packaging R Quarto Cli

[Wojtek Kosior via]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

> Hi,
> 
> Some news about *Quarto* Packaging :

Hi!

It's amazing to still see you pushing this forward ^^

> ## Packaging Quarto
> 
> After running ./configure.sh i get the next step from conda recipe 
> (https://github.com/quarto-dev/quarto-cli/tree/main/package/conda-recipe/build.sh).
> 
> Conda recipe generate a standalone bundle (a ./quarto (sh) and a 
> ./quarto.js) by using this shell script : 
> https://github.com/quarto-dev/quarto-cli/blob/main/package/src/quarto-bld
> 
> As you could see in the code, quarto-bld run Deno with some options, one 
> refer to some .json, that contain lot of thing to download into 
> /vendors. But it seems this part is not activated if the 
> QUARTO_VENDOR_BINARIES env is set to false.
> 
> (A) / quarto-bld update-html-dependencies
> (B) / quarto-bld prepare-dist
> 
> The A step call this thing 
> (https://github.com/quarto-dev/quarto-cli/blob/main/package/src/common/update-html-dependencies.ts) 
> that download and patch some file into the project.
> 
> So, A is a problem, and i need to patch this typescript file to give 
> directly the file without downloading it from internet.
> 
> *How could i create an archive that contain already these different 
> files to my quarto build ? *
> 
> *Do you think building a git repo with all of them is a good idea ?* 
> Even if these files are linked to multiple sources : https://unpkg.com/; 
> https://github.com/ ; 
> https://github.com/mozilla/pdf.js/releases/download/ ; 
> https://github.com/twbs/icons/releases/download/

What I'd do is make each of those into a distinct package or even
better — obtain the remote files by creating and then ungexp'ing an
(origin) object for each of them.

To clarify what I mean, let's look at how the `gnome-recipes` packaging
resolves the problem of pulling multiple sources for the build[1].

After so much work on Quatro you're probably already such a guile guru
that no further explanation is needed here :)

> If i download these file by running manually (A) in /tmp after a fail 
> build, the (B) command build a working "./quarto --help" and "./quarto 
> check" command, so end is near \o/

Great! Good luck again :)

Wojtek


[1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnome.scm?id=2336d5f57a4422d9c97db85e1c9a47763f23ad3c#n843

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]