[bitbake-devel] [PATCH 1/5] lib/layers: Initial layer and layer index implementeation

[Paul Eggleton]

On Friday, 28 July 2017 5:37:18 PM CEST Mark Hatle wrote:
> This module provides two components, layerindex, which is used to talk a
> layerindex, such as layers.openembedded.org.
> 
> The other module is the 'manager'.  This module will handle downloading,
> re-writing the bblayers to match the downloads and other related layer
> management tasks.

It's great to have a solid internal API for interacting with the layer index 
to replace the less than optimal earlier implementation in bitbake-layers - 
thanks for sorting this out. The only comments I'd make:

1) Can you rename the fetch2 plugin to something like bbfetch or bitbakefetch 
or something like that. I'd rather we didn't proliferate the fetch2 name any 
further - IIRC Richard has talked about renaming the module back to fetch at 
some point.

2) cooker.py has a "## TODO NOT IMPLEMENTED" comment that if still valid needs 
to be expanded upon - what's actually missing? There's also a moderate size 
block of commented-out code just below that, since this is new can we drop 
that if it's genuinely not needed?

3) Can we have a default type for layerindex URLs of "restapi" so we don't 
need to specify this everywhere in the common case? This would also mean we 
wouldn't have to change DEFAULT_LAYERINDEX_SERVER in the toaster code.

4) The "layers" naming of the module under lib is a little confusing given 
that we already have a bblayers module under lib/, and one might incorrectly 
assume that this was used for all layer handling. I don't actually yet have a 
naming scheme / structure I like better though :(

5) "OR" to split the branches is a very awkward. Can we use , (comma) instead?

6) I'm not massively thrilled at duplicating the layer index data structures 
in bitbake. It does make things easier on the bitbake side, and the 
alternative of making use of the original django models in bitbake isn't 
practical, but it's just a bit unfortunate in terms of future maintenance. 
Having said that we made the same choice in Toaster, and the layer index 
models don't change that often. (I guess I'm just highlighting this so we know 
what we're getting into.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre