all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Allan Webber <cwebber@dustycloud.org>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: On merging the npm importer
Date: Wed, 29 Mar 2017 12:39:35 -0500	[thread overview]
Message-ID: <87vaqsaso8.fsf@dustycloud.org> (raw)
In-Reply-To: <87zig5mj5c.fsf@gnu.org>

Jan Nieuwenhuizen writes:

> Hi,

Hi Jan!

> We have a working importer for npm packages written by Jelle that I have
> been using for about half a year.  It can use some improvements and
> that's why I think we should merge it.
>
> Have alook at my npm branch here, rebased on master
>
>     https://gitlab.com/janneke/guix

Would like to review soon, though I'll say that I think unless there are
serious problems, we should probably merge it.  Avoiding bitrot is prety
important, and at the very least I don't think it will hurt to have it
merged.

> I added a patch with several fixes for the importer and and build
> system.  So far, so good.
>
> There's a problem however with the --recursive option and the build
> system.  To quote Jelle[1]
>
>    To start of with something that did not work out as well as I had
>    hoped, getting a popular build system (e.g. Gulp, Grunt, Broccoli and
>    others) packaged.  As mentioned in my earlier mails, the list of
>    transitive dependencies of any of these suffer from at least the
>    following:
>
>    - It is a list with more than 4000 packages on it
>    - It is a list with at some point the package itself on it
>
> Most nontrivial npm packages use a build system, and all build systems
> have circular development dependencies.  Not all development
> dependencies are always required to build a package, but some certainly
> are nd there's no way to tell which is which, afaik.
>
> That's why I added a --binary option to the importer: it will not
> try to use the build system and instead mimick `what npm does.'  This
> does provide, however, an amazing reproducibility feature to the
> dependency woes that npm hackers are familar with.
>
> I suggest to not add any npm package to Guix that is the result of using
> the --binary option and to build a base of full-source/sanitized npm
> packages.

Cool... makes sense to me to have this as something we don't use for
Guix packages, but which might make Guix more useful for people who have
to use npm in the awkward "real world" that is the current state of npm.

> Greetings, janneke
>
> [1] https://lists.gnu.org/archive/html/guix-devel/2016-08/msg01567.html

  reply	other threads:[~2017-03-29 17:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28 16:59 On merging the npm importer Jan Nieuwenhuizen
2017-03-29 17:39 ` Christopher Allan Webber [this message]
2017-03-30 14:22   ` Jelle Licht
2017-03-30 16:39     ` Jan Nieuwenhuizen
2017-03-30 14:50   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vaqsaso8.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=guix-devel@gnu.org \
    --cc=janneke@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.