[OE-core] npm.bbclass

Paul Eggleton paul.eggleton at intel.com
Wed Aug 17 12:40:23 UTC 2016


Hey Chris, long time!

On Wed, 17 Aug 2016 11:11:13 Brendan Le Foll wrote:
> >    - 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...

Right, that is why we do the splitting - if you want the licenses and actual 
packages used to be fully represented in the image license manifest then they 
really do have to be split this way. Honestly I view this ugliness more as an 
artifact of how npm works (i.e. every dependency is handled separately instead 
of trying to ensure only one instance of a particular package).

> 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.

Sure, but rather than a separate class I would just add a variable such as 
NPM_SPLIT_PACKAGES that defaults to "1" and then you can set it to "0" either 
globally or in each recipe.

> >    - 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 :)

This is definitely not intentional, but the way we have been dealing with npm 
it makes it easy for stuff like this to leak into the output packages. I guess 
we just need to delete them under ${D} after the files are installed there.

Cheers,
Paul



More information about the Openembedded-core mailing list