From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [GSoC] Integrating npm into the Guix ecosystem Date: Wed, 08 Jun 2016 15:14:09 +0200 Message-ID: <871t47j00u.fsf@gnu.org> References: <87bn3dizp9.fsf@gmail.com> 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]:60265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAdJJ-0007kN-N7 for guix-devel@gnu.org; Wed, 08 Jun 2016 09:14:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAdJF-0001Lh-EU for guix-devel@gnu.org; Wed, 08 Jun 2016 09:14:16 -0400 In-Reply-To: <87bn3dizp9.fsf@gmail.com> (Jelle Licht's message of "Tue, 07 Jun 2016 02:56:34 +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: > It has been some time since my last mail to this list, so I wanted to > share what I have been up to. For the people who might want to watch > along after today, I will be posting the changes that should not break > everything immediately to [1]. Glad to see there=E2=80=99s already a build system and an importer! I think it=E2=80=99s indeed a good idea to have them in master early. That= will hopefully allow others to give it a try and provide feedback. As a pre-review ;-), could be make sure you add a bunch of tests for the importer (see tests/{cran,cpan,elpa,gem,hackage}.scm for examples), and mention =E2=80=98node-build-system=E2=80=99 under =E2=80=9CBuild Systems=E2= =80=9D in doc/guix.texi? > The current importer functions as expected for the "90%" of packages > that I tried. A problem that I ran into that I could not recognize as > easily in other importers is the fact that the npm community only > distributes the artifacts that you need to run the npm modules, but not > to build them. In most trivial cases, there are literally no > differences, but especially for more complicated packages involving > transpilation steps, this poses a problem. > > As such, the importer can not actually 'know' of the location of the > source. Right now it uses some limited heuristics to probe GitHub > repositories for a tarball release, and if these are not found or the > sources are hosted at non-GH sites, it tries to check out a tag > according to the npm packaging conventions (SemVer). Interesting. > The most important thing that needs to happen right now would be to > extend the range of packages that are buildable by the build system. A > combination of working towards having working 'large' packages and test > frameworks should help me quickly identify problems. This will be my > main focus for the next week. Sounds like you=E2=80=99re on the right track. :-) I=E2=80=99m not qualified to comment on the specific npm issues. I think y= ou may be interested in the recursive importer that Ricardo recently submitted for CRAN, because recursive imports probably makes a lot of sense for a report as big as npm (as in =E2=80=98guix import npm -r jquery= =E2=80=99). Thanks for the update! Ludo=E2=80=99.