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 <jann...@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
