From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Lepiller Subject: Re: NPM importer Date: Tue, 20 Nov 2018 23:35:45 +0100 Message-ID: <20181120233545.16257e58@lepiller.eu> References: <70F182DB-C157-4763-A4C6-89985545661C@lepiller.eu> <0e5afb2d-c182-6be4-ba2d-6a6f7dd45ac9@riseup.net> <1150DF84-4952-4401-A8D0-3E05A4D0EB74@lepiller.eu> <23f36a0d-a5ef-5457-1d8e-61fbebda91c4@riseup.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPEd7-000408-1j for guix-devel@gnu.org; Tue, 20 Nov 2018 17:36:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPEd3-000384-Iv for guix-devel@gnu.org; Tue, 20 Nov 2018 17:36:24 -0500 Received: from lepiller.eu ([2a00:5884:8208::1]:36788) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gPEd3-0002se-8x for guix-devel@gnu.org; Tue, 20 Nov 2018 17:36:21 -0500 In-Reply-To: <23f36a0d-a5ef-5457-1d8e-61fbebda91c4@riseup.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: swedebugia , guix-devel@gnu.org Le Tue, 20 Nov 2018 22:12:18 +0100, swedebugia a =C3=A9crit : > Hi >=20 > On 2018-11-20 20:58, swedebugia wrote: > > On 2018-11-20 08:50, Julien Lepiller wrote: =20 >=20 > snip >=20 > >> See this script that builds a graph of dependencies, ignoring=20 > >> devDependencies (so none of the packages listed by this script is=20 > >> going to be tested): > >> https://framagit.org/tyreunom/guix/snippets/2534 =20 >=20 > What is devDependencies? Required to build the npm package? the package.json file declares two kinds (I think I've seen a third kind, but I'm not sure, nor am I a js developper) of dependencies: dependencies and devDependencies that map to our inputs and native-inputs. devDependencies are tools used during the build or development, but they are not needed at runtime. Sometimes, they are required at build time (for instance the coffeescript compiler is a devDependencies of some packages, but we need it to build the package), usually they are required at test time (for instance mocha, tap, or tape are test frameworks), otherwise, they can be documentation tools, and sometimes really not useful for us (we probably don't want to run linters or release-related tools). >=20 > I understood the script now I think. :) >=20 > I replaced "mocha" with name in the call in the bottom. >=20 > Then did: > $guile > scheme@(guile-user)> (define name "ssb-patchwork") > scheme@(guile-user)> (load "npm-explorer.scm") > ... The way I wrote it, you were supposed to change the "mocha" with the package you're interested in, and run the script with guile like so: guile npm-explorer.scm > mocha.dot and then: fdp -Tpng mocha.dot > mocha.png (fdp is part of graphviz, but produces nicer graphs than dot in my opinion) >=20 > As you said it runs for(ever) (in my case 5 minutes) listing=20 > dependencies of dependencies of dependencies of dependencies of=20 > dependencies of dependencies ... >=20 > 1100 last lines of the output is attached. :p >=20 > One thing is for sure. There are a LOT of npm packages. "Over 477,000=20 > packages are available on the main npm registry." according to WP. :O That's probably the number of packages on which depend any node packages through its dependencies and devDependencies... I suspect you can always find a path between any two packages in this graph... in either direction. >=20 > I wonder how many are free software? 90%? 50%? >=20 > I hope we can automate this some way. It looks very difficult, but if you have any ideas, please tell us! >=20 > npm.scm will be a VERY VERY long file. Maybe we should rethink about > how to best store all these variables... Very long files are frowned upon, because they have very long compilation times and require a lot of memory. We'll have to find a way to split the file before it grows too much. Maybe we will do something similar than python packages? We have python.scm, python-web.scm... >=20 > Just 1 npm application (ssb-patchwork) will add at least 1000 package=20 > definitions to it. >=20