From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jelle Licht Subject: [GSoC update] Npm & guix Date: Sun, 24 Jul 2016 03:06:52 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01228720799b2f053857482b Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bR7so-0007v5-9P for guix-devel@gnu.org; Sat, 23 Jul 2016 21:07:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bR7si-0004cy-7A for guix-devel@gnu.org; Sat, 23 Jul 2016 21:07:05 -0400 Received: from cavendish.fsfeurope.org ([2001:aa8:ffed::3:102]:57264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bR7sh-0004ck-PP for guix-devel@gnu.org; Sat, 23 Jul 2016 21:07:00 -0400 Received: from localhost (localhost [127.0.0.1]) by cavendish.fsfeurope.org (Postfix) with ESMTP id C92C163B9C1 for ; Sun, 24 Jul 2016 03:06:57 +0200 (CEST) Received: from cavendish.fsfeurope.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI3+8I9z+kCu for ; Sun, 24 Jul 2016 03:06:54 +0200 (CEST) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: jlicht) by cavendish.fsfeurope.org (Postfix) with ESMTPSA id 8F03B63B9BC for ; Sun, 24 Jul 2016 03:06:54 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id f65so96391811wmi.0 for ; Sat, 23 Jul 2016 18:06:54 -0700 (PDT) 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: guix-devel --089e01228720799b2f053857482b Content-Type: text/plain; charset=UTF-8 Hello Guix! After hopefully enough contemplation and a lot of elbow grease, I would like to give you an overview of what I have been up to these past weeks. To start off with something that might make some people less than happy; jQuery and its dependencies will most likely not be packaged this summer. By me, at least. 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. While this is a sad realization indeed, it just makes it easier to focus on other important packages of npm. Running the recursive importer on a handful of packages leads me to the following possibly redundant observations: * Quite some packages have tests (Yay!) * Running tests requires test frameworks and test runners 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. 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. A goal of this project is still to have a working jQuery by the end of this summer, just not via the procedures defined by npm. My current plan is to partially reimplement the build procedures used for jquery, albeit in a much simpler manner: just a single, some might say bloated, javascript file created from the sources, instead of the a-la-carte build afforded by Grunt. In this approach, I also see something that might make packaging npm packages more Guix-friendly: as long as we have _functional_ equivalents, we should be able to build a huge subset of packages. This can be either a blessed version of an npm package, or a simplistic yet correct reimplementation, depending on the complexity of the specific package. This would only work for build-time dependencies, or native-inputs. Thanks for reading this WoT and looking forward to hearing your feedback. - Jelle --089e01228720799b2f053857482b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Guix!

After hopefully enough contemplati= on and a lot of elbow grease, I would like to
give you an overview of wh= at I have been up to these past weeks.

To start off with something t= hat might make some people less than happy; jQuery
and its dependencies = will most likely not be packaged this summer. By me, at
least.

On= Ludo's advice, I snarfed Ricardo's recursive importer and bolted i= t on my npm
importer. After leaving the importer running for a quite som= e hours (and making
it more robust in the face of inconsistent npm infor= mation), it turns out that
jQuery has a direct or indirect dependcy on a= bout everything. We are talking
pretty much all of the build systems, al= l of the testing frameworks and all of
the test runners. Literally thous= ands of packages, and multiple (conflicting)
versions of most.

Wh= ile this is a sad realization indeed, it just makes it easier to focus onother important packages of npm. Running the recursive importer on a hand= ful of
packages leads me to the following possibly redundant observation= s:

* Quite some packages have tests (Yay!)
* Running tests requir= es test frameworks and test runners

This makes it IMHO a worthwhile = goal bootstrap to a working test framework, with
of course at first test= s 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)
compi= ler, and the awesome git-bisect command, I was able to subsequently compile=
and use the more modern (but still old) Coffeescript-in-coffeescript co= mpilers.

I am currently hovering between version 0.6 and 0.7, which = can properly
recompile itself and slightly more contemporary version. Ge= tting to version
1.6 from June 2013 should be doable using this exact sa= me approach. This will
allow us to package a 2014 version of the Mocha t= esting framework.

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 n= eed to start somewhere, by packaging
things back when they did not have = as many dependencies. Currently, I have a
file containing implementation= s of old Node (pre 1.0) functionality on Node 6.0.
I was thinking of rel= easing 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, th= is already forces us to
have 3~4 versions of Node, although it is conce= ptually a lot cleaner.

So my current view of our options:
* Back= port ancient node features to a contemporary node version
* Package a si= gnificant variety of node versions
Please let me know if anyone has some= thoughts, critiques or silver bullets for this
problem.

A goal = of this project is still to have a working jQuery by the end of this summer= , just
not via the procedures defined by npm. My current plan is to part= ially
reimplement the build procedures used for jquery, albeit in a much= simpler
manner: just a single, some might say bloated, javascript file = created from the
sources, instead of the a-la-carte build afforded by Gr= unt.

In this approach, I also see something that might make packaging npm=20 packages more Guix-friendly: as long as we have _functional_=20 equivalents, we should be able to build a
huge subset of packages. This= can be either a blessed version of an npm package, or a
simplistic yet = correct reimplementation, depending on the complexity of the specific
package. This would only work for build-time dependencies, or native-in= puts.

Thanks for reading this WoT and looking forward to hearin= g your feedback.

- Jelle
--089e01228720799b2f053857482b--