unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jelle Licht <jlicht@fsfe.org>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: NPM and trusted binaries
Date: Thu, 08 Sep 2016 10:29:13 +0200	[thread overview]
Message-ID: <87k2em6bhi.fsf@gmail.com> (raw)
In-Reply-To: <20160908070125.GA27108@thebird.nl>


Just a quick note from me;

AFAIK, the http module is a built-in of node, so you can probably save
yourselves the efforts of packaging it ;-).

Furthermore, lots of development dependencies are not strictly
necessary; e.g. a minifier/uglifier is not required for most
functionality of a package, and ditto for linters and to a certain
extent test frameworks, at least for our initial set of node packages.
This initial set of packages can then (hopefully) be used to package the
rest of npm properly, including tests etc.

The biggest issue here is that an importer can not decide for you which
devDependency is actually is needed to properly build a source archive,
and which just provides convenience functions. The importer should
become more useful when we have a solid set of npm packages in guix.
Before that, the importer will probably be useful to a lesser degree for
any packages besides the most trivial.

Regarding feasibility and its weight, I would say that a simple
transformation such as concatenating files should not be an issue,
whereas more involved transformations such as tree shaking,
uglification, or tranpilation do involve a transformation that take away
much of our freedoms to modify the software, at least in practice.

- Jelle

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Wed, Sep 07, 2016 at 07:51:46PM +0200, Jan Nieuwenhuizen wrote:
>> 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.
>
> Mission is fine and I agree with that (in principle).
>
>> 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?
>
> I think we are clear we do not want binaries in the main project
> unless there is no way to do it from source.
>
> Personally I think we should be easier on ourselves which implies that
> we get multiple flavours of Guix. 
>
> Another reason to make 'guix channels' work.
>
> Pj.

  reply	other threads:[~2016-09-08  8:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  9:07 GSoC NPM Jelle Licht
2016-08-25 10:24 ` Ricardo Wurmus
2016-08-27 13:12   ` Jelle Licht
2016-09-06 23:21     ` Catonano
2016-08-27 21:43 ` Ludovic Courtès
2016-09-06 20:00   ` Christopher Allan Webber
2016-09-02 14:24 ` Jan Nieuwenhuizen
2016-09-02 15:27   ` Thompson, David
2016-09-02 16:23     ` Jan Nieuwenhuizen
2016-09-02 15:33   ` Jelle Licht
2016-09-04 14:11     ` Jan Nieuwenhuizen
2016-09-06 15:48       ` Thompson, David
2016-09-06 16:50         ` NPM and trusted binaries Pjotr Prins
2016-09-07 12:25           ` Ludovic Courtès
2016-09-07 17:51             ` Jan Nieuwenhuizen
2016-09-08  7:01               ` Pjotr Prins
2016-09-08  8:29                 ` Jelle Licht [this message]
2016-09-08  2:45           ` Mike Gerwitz
2016-09-08  8:45             ` Jan Nieuwenhuizen
2016-09-08 17:31               ` Mike Gerwitz
2016-09-08 19:54                 ` Jan Nieuwenhuizen
2016-09-09  0:31                   ` Mike Gerwitz
2016-09-09  8:45                     ` Ludovic Courtès
2016-09-09  9:26                       ` Pjotr Prins

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87k2em6bhi.fsf@gmail.com \
    --to=jlicht@fsfe.org \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).