help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help packaging R Quarto Cli


From: Sébastien Rey-Coyrehourcq
Subject: Re: Help packaging R Quarto Cli
Date: Thu, 27 Oct 2022 09:05:52 +0200
User-agent: mu4e 1.8.9; emacs 28.2

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
>>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]