Re: [GSoC update] Npm & guix

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Jelle Licht <jlicht@fsfe.org> 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’m really impressed that your importer can already grovel this much!
In itself, that’s already a significant achievement, despite the
frustration of not getting “guix package -i jquery” right away.

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’s 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’ve never managed to get this far for the other compilers we
have.

Thanks for the status update!

Ludo’.