[OE-core] npm class usage

[Paul Eggleton]

Right, this is the problem Brendan was describing - I believe I sent a patch 
to fix this already:

http://patchwork.openembedded.org/patch/121039/

Cheers,
Paul

On Thu, 05 May 2016 09:51:53 Fabio Berton wrote:
> Hi Paul,
> 
> When running:
> recipetool create "npm://registry.npmjs.org;name=grunt-cli;version=1.1.0"
> 
> I get this error:
> 
> NOTE: Unpacking abbrev-1.0.7.tgz to
> /tmp/recipetool-tXXZDi/npmpkg/node_modules/nopt/node_modules/abbrev/
> Traceback (most recent call last):
>   File "sources/openembedded-core/scripts/recipetool", line 116, in <module>
> ret = main()
>   File "sources/openembedded-core/scripts/recipetool", line 107, in main
>     ret = args.func(args)
>   File "sources/openembedded-core/scripts/lib/recipetool/create.py", line
> 561, in create_recipe
>     handler.process(srctree_use, classes, lines_before, lines_after,
> handled, extravalues)
>   File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
> line 133, in process
>     license = self._handle_license(pdata)
>   File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
> line 44, in _handle_license
>     if 'license' in data:
> TypeError: argument of type 'NoneType' is not iterable
> 
> 
> On Thu, May 5, 2016 at 7:57 AM, Brendan Le Foll <brendan.le.foll at intel.com>
> 
> wrote:
> > On Thu, May 05, 2016 at 07:10:43PM +1200, Paul Eggleton wrote:
> > > Note also that devtool add / recipetool create are capable of creating
> > 
> > pretty
> > 
> > > complete recipes for npm packages where licenses are also correctly set
> > 
> > per
> > 
> > > package (so you get them in the image manifest). I'd strongly recommend
> > 
> > using
> > 
> > > it for this; if you have any issues please let me know.
> > 
> > So actually it errors in this case because of a test package in the
> > resolve module (this shows the issue quicker/easier) see:
> > $ recipetool create "npm://registry.npmjs.org;name=resolve;version=1.1.7"
> > 
> > There's a node_modules dir inside test/ it gets taken as if npm had
> > resolved/download a dep when in fact it hasn't. Since node packages
> > can and do ship their own deps with them sometimes, I think the only
> > fix would be in npm_split_package_dirs to walk 1 level of the ${PN}
> > dir only so that:
> > 
> > ${PN}/node_modules -> taken
> > ${PN}/tests/node_modules -> ignored
> > ${PN}/node_modules/${PN}/node_modules -> taken
> > 
> > Cheers,
> > Brendan

-- 

Paul Eggleton
Intel Open Source Technology Centre