guix-devel
[Top][All Lists]
Advanced

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

Re: GSoC NPM


From: Jelle Licht
Subject: Re: GSoC NPM
Date: Sat, 27 Aug 2016 15:12:09 +0200
User-agent: mu4e 0.9.16; emacs 24.5.1

Hi

Ricardo Wurmus <address@hidden> writes:

> Hi
>
>> I also took both Ludovic', as well as Catonano's detailed feedback on the
>> initial draft of the recursive importer into account when rewriting it. It
>> should now only visit each node in the dependency graph once, and be a
>> whole lot
>> more efficient as well. It is still based on the multi-valued return values
>> that drove Ricardo's initial work on the CRAN recursive importer.
>
> [...]
>
>> After rewriting the recursive importer to be
>> more
>> sane, I scrawled some notes on my notepad that basically boil down to the
>> following:
>> 1. We should only look up each npm package once, if possible
>> 2. We should have a list of all npm package names.
>> 3. We should be able to specify the maximum traversal depth
>
> I’m not sure I understand.  The CRAN recursive importer visits
> packages only once because it keeps track of previously imported
> packages (in addition to those that are already in Guix).


With the recursive fold approach, I had the issue that
sometimes packages that were imported in a 'leaf fold' had to be
imported again in a different 'leaf fold'. This might very well also be
a mistake I made in my original adaptation of the CRAN importer ;-).

If the general consensus on the ML is that using higher order functions
+ recursion is more elegant than a big, bold loop, I can still
reimplement it as such.

>
>> An easy-yet-inelegant solution would be to include the package name as used
>> within the npm registry as metadata via an argument to the
>> node-build-system.
>
> That’s not so inelegant; or at least we have precedent in Guix.  For
> CRAN and Bioconductor packages we often add something like this:
>
>     (properties `((upstream-name . "ACSNMineR")))
>
> This is already used by the updater.

Well, that is most likely what I will be implementing then. An
advantage of this is that it would also make my life easier when making
runtime npm module loading more robust :-).

>
> ~~ Ricardo

Thanks for your feedback

- Jelle




reply via email to

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