From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [GSoC update] Npm & guix Date: Mon, 25 Jul 2016 23:26:23 +0200 Message-ID: <8737mxflz4.fsf@gnu.org> References: 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]:45532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRnOR-0004GM-Ki for guix-devel@gnu.org; Mon, 25 Jul 2016 17:26:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRnON-0007yM-EF for guix-devel@gnu.org; Mon, 25 Jul 2016 17:26:30 -0400 In-Reply-To: (Jelle Licht's message of "Sun, 24 Jul 2016 03:06:52 +0200") 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: Jelle Licht Cc: guix-devel Hello! Jelle Licht skribis: > On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it > on my npm importer. After leaving the importer running for a quite > some hours (and making it more robust in the face of inconsistent npm > information), it turns out that jQuery has a direct or indirect > dependcy on about everything. We are talking pretty much all of the > build systems, all of the testing frameworks and all of the test > runners. Literally thousands of packages, and multiple (conflicting) > versions of most. I=E2=80=99m really impressed that your importer can already grovel this muc= h! In itself, that=E2=80=99s already a significant achievement, despite the frustration of not getting =E2=80=9Cguix package -i jquery=E2=80=9D right a= way. Do you have figures on the number of vertices and edges on this graph? Could it be that the recursive importer keeps revisiting the same nodes over and over again? :-) I would suggest publishing the code somewhere so others can try to import their favorite JS library and give feedback. > This makes it IMHO a worthwhile goal bootstrap to a working test > framework, with of course at first tests disabled for the dependencies > of this test framework. Test frameworks all have an (indirect) > dependency on the Coffeescript compiler, of which the first version > was written in Ruby. Using this initial (alpha) compiler, and the > awesome git-bisect command, I was able to subsequently compile and use > the more modern (but still old) Coffeescript-in-coffeescript > compilers. > > I am currently hovering between version 0.6 and 0.7, which can > properly recompile itself and slightly more contemporary > version. Getting to version 1.6 from June 2013 should be doable using > this exact same approach. This will allow us to package a 2014 > version of the Mocha testing framework. Impressive. > For the people more knowledgeable in these matters, how would you deal > with deprecated functionality in languages such as python, ruby etc? > Because npm packages are so interdependent, I simply need to start > somewhere, by packaging things back when they did not have as many > dependencies. Currently, I have a file containing implementations of > old Node (pre 1.0) functionality on Node 6.0. I was thinking of > releasing this 'hack' as an npm package and then package it in Guix. > > The alternative would be to package each version of Node that was used > to build these ancient packages. For bootstrapping Coffeescript, this > already forces us to have 3~4 versions of Node, although it is > conceptually a lot cleaner. > > So my current view of our options: * Backport ancient node features to > a contemporary node version * Package a significant variety of node > versions Please let me know if anyone has some thoughts, critiques or > silver bullets for this problem. People have looked at bootstrapping compilers using their historical ancestor, and it often looked hard first to find what each implementation=E2=80=99s ancestor was, and then to actually chain them (I remember Ricardo going back to an old Haskellish implementation in Scheme at one point.) Of the two options you list, packaging several Node versions sounds like the simplest one. There may be other stumbling blocks though, so be prepared to stop the packaging recursion before you get mad. ;-) In practice, we=E2=80=99ve never managed to get this far for the other compile= rs we have. Thanks for the status update! Ludo=E2=80=99.