guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NPM and trusted binaries


From: Jan Nieuwenhuizen
Subject: Re: NPM and trusted binaries
Date: Wed, 07 Sep 2016 19:51:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ludovic Courtès writes:

>> Still, I think Guix would benefit from a somewhat more relaxed stance
>> in this.
>
> It’s part of Guix’s mission to build from source whenever that is
> possible, which is the case here, AIUI.

Yes, I thought so too...I shared my findings to get more viewpoints on
this assertion and also on the validity of the source/binary metaphor
for npm packages.

I spent the weekend to attempt building `q' using the repository+version
= source package metaphor.  Because given the facts that

  * an npm package must specify a name and a version
  * an npm package may optionally list a source repository
  * an npm package may optionally lists devDependencies
  * using repository + the devDepencies you can build the installable
    npm package

I also thought it would be nice to build as many packages as possible
from their repsository urls.  I encountered several small problems with
the importer (or with inconsistencies/breakages in npm packages) that I
fixed.

Quoting my earlier mail

   ... that resulted in over 6004 dependencies (using build systems
   grunt, gulp and node-gyp, listing 582 errors)

Finally, I became discouraged and Sunday night I added the --binary flag
to the importer, decided to taint the resulting package description
doing

  (arguments `(#:binary #t))

to enable breaking this enormous dependency chain.  How many more
package dependencies will result from the 582 packages that have import
problems?

Oh, please note that the `binary' or installable version of this `q'
package consists of two javascript files: q.js and query.js which are
identical to the ones in the `source' package.  The git repository
additionally has tests and documentation (and history).

Another example is the `http' package: it does not list a repository url
and the installable package is plain readable javascript.  Does the
source/binary metaphor apply here?

The `fibers' package comes with precompiled binaries for popular
platforms.  It also includes all C sources to build these binaries.  It
could be possible that some npm package has only minimalized javascript
(i.e.: can really be considered binary) but I haven't seen such a
package yet.

WDYT, do we have enough information to decide if building from `source'
the right metaphor?  Is it pracically feasible and does feasibilty have
any weight?  What's the next step I could take to help to bring `q' and
`http' (and the other 316 packages I need) into Guix?

Greetings,
Jan

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]