Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Brendan Le Foll <brendan.le.foll@intel.com>
To: Christopher Lord <clord@mozilla.com>
Cc: paul.eggleton@intel.com, openembedded-core@lists.openembedded.org
Subject: Re: npm.bbclass
Date: Wed, 17 Aug 2016 11:11:13 +0100	[thread overview]
Message-ID: <20160817101112.GA20728@hippo.iwi.intel.com> (raw)
In-Reply-To: <CABDc_zW0Mi9a5G+neZMSAC5mRVo8LC-62ew_X9PiKM8uVxhAUA@mail.gmail.com>

On Tue, Aug 16, 2016 at 05:41:28PM +0100, Christopher Lord wrote:
>    I've been using npm.bbclass with various node projects we're working on
>    in the Connected Devices team at Mozilla, and had some
>    questions/comments about behaviour (note that I'm basing this off of
>    ostro master, which I unfortunately have to use as no other Intel
>    Edison bsp is adequate);

I'm sorry :/

>    - Is there a good reason the npm fetcher only works with a registry? It
>    seems it could get most (all?) pertinent information from a
>    package.json in the root of a repository.

Not really a good reason, I'm trying to make it so that you can use it
with a git fetched source but I haven't had the time to finish it off.
It's on the todo list :)

>    - Is there a reason to split the package like it does? Node projects
>    tend to have huge dependency trees, it makes updating and distributing
>    node-based applications a bit of a chore if they end up split into 20
>    packages, most of which have no use separately. It would be great if
>    there was at least a way to disable this.

Paul added this, the worry was that we wanted to make sure all the
licenses where tracked properly of the package etc... I'm not a huge
fan either to be honest. Maybe we can have a npm-no-split.bbclass
would that be ok - Paul? It's in python populate_packages_prepend in
npm.bbclass.

>    - The information about packaging non-registry software here:
>    [1]https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM is incomplete -
>    you also need to generate a shrinkwrap and install that into the
>    srcdir, or you're very likely to get failures doing dependency
>    resolution. Not an OE issue, but I guess Yocto folks also read this
>    list and it's related :)

Agree 100%, that is still WIP, Henry can you make sure you add a how
to use the npm lockdown file too in the tutorial? Note - If you use
recipetool It does this by default :). And recipetool with node.js
pkgs is quite cool imho.

>    - Any patches end up getting packaged because they get put in the
>    srcdir. I'm guessing this isn't intentional (or maybe it is?)
>    Just wanted to provide some feedback. It's fantastic that OE has the
>    ability to package node software, and despite the teething
>    difficulties, I've appreciated its availability!

That is a good point, didn't think about it tbh. in npm.bbclass we
could maybe delete everything that looks like a patch before
compilation, little bit worried there might be nasty side effects but
I can try :)

Thanks for the comments!
Brendan



  parent reply	other threads:[~2016-08-17 10:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 16:41 npm.bbclass Christopher Lord
2016-08-16 16:48 ` npm.bbclass Burton, Ross
2016-08-17 10:11 ` Brendan Le Foll [this message]
2016-08-17 12:40   ` npm.bbclass Paul Eggleton
2016-08-17 13:58     ` npm.bbclass Christopher Lord

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=20160817101112.GA20728@hippo.iwi.intel.com \
    --to=brendan.le.foll@intel.com \
    --cc=clord@mozilla.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@intel.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox