Hi, Wojtek Kosior 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 : 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: > PGP: > 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 > > – (sig_end) > > > On Thu, 27 Oct 2022 09:05:52 +0200 > Sébastien Rey-Coyrehourcq 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 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: >> > >> > 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: >> > PGP: >> > 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 >> > >> > – (sig_end) >> > >> > >> > On Tue, 25 Oct 2022 12:08:59 +0200 >> > zimoun wrote: >> > >> >> Hi, >> >> >> >> On Mon, 24 Oct 2022 at 20:40, Wojtek Kosior via 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: >> >> >> >> Cheers, >> >> simon >> >> >> > >> > > >