[Top][All Lists]

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

On merging the npm importer

From: Jan Nieuwenhuizen
Subject: On merging the npm importer
Date: Tue, 28 Mar 2017 18:59:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)


We have a working importer for npm packages written by Jelle that I have
been using for about half a year.  It can use some improvements and
that's why I think we should merge it.

Have alook at my npm branch here, rebased on master

I added a patch with several fixes for the importer and and build
system.  So far, so good.

There's a problem however with the --recursive option and the build
system.  To quote Jelle[1]

   To start of with something that did not work out as well as I had
   hoped, getting a popular build system (e.g. Gulp, Grunt, Broccoli and
   others) packaged.  As mentioned in my earlier mails, the list of
   transitive dependencies of any of these suffer from at least the

   - It is a list with more than 4000 packages on it
   - It is a list with at some point the package itself on it

Most nontrivial npm packages use a build system, and all build systems
have circular development dependencies.  Not all development
dependencies are always required to build a package, but some certainly
are nd there's no way to tell which is which, afaik.

That's why I added a --binary option to the importer: it will not
try to use the build system and instead mimick `what npm does.'  This
does provide, however, an amazing reproducibility feature to the
dependency woes that npm hackers are familar with.

I suggest to not add any npm package to Guix that is the result of using
the --binary option and to build a base of full-source/sanitized npm

Greetings, janneke


Jan Nieuwenhuizen <address@hidden> | GNU LilyPond
Freelance IT | Avatar®  

reply via email to

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