Hi Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> 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
