All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH 0/5] Add a standard module for accessing the layerindex
Date: Tue, 17 Jul 2018 22:37:50 +0200	[thread overview]
Message-ID: <2844607.YnhVh9u1Q8@localhost.localdomain> (raw)
In-Reply-To: <cdb1b25d-9448-a43c-d345-7af3a5674a58@windriver.com>

Hi Mark

On Thursday, 12 July 2018 11:07:06 PM CEST Mark Hatle wrote:
> On 7/12/18 3:34 PM, Mark Hatle wrote:
> > In order to simply existing components, and add support to create some
> > new functionaly -- we need a common apporach for access the layerindex.
> > 
> > The class supports loading multilib layerindexes, but right now that
> > functionality is not being used by either bitbake-layers or the toaster.
> > 
> > There are a few 'TODO' items that remain in the code.  These are related
> > to either un-implemented, but planned functionality or to display stuff
> > in bitbake-layers.  I'm hoping that part of this review can discuss the
> > TODO items.

This looks good, thanks - great to start to have a client API that we can use 
in a bunch of different places. Some comments:

1) LAYERSERIES_CORENAMES is treated by bitbake as a list. At the moment it's 
just one item, but we should treat it the same here - for now we can probably 
take the easiest way out and just split it and take the first item.

2) I feel like the ;type= stuff is an unnecessary complication. Can we not 
just treat http URLs as being restapi and local:// (or something similarly 
simple) as being the local configuration? The plugins could simply have a 
function that returns True if it can handle the URL, as we do in bb.fetch2, 
and we take the first one that returns True or error out if none do.

3) "except Exception" is too broad, can we catch a specific exception class or 
classes instead?

4) From an API perspective, it seems to me that we should be taking lists 
everywhere rather than space-delimited strings e.g. in get_dependencies() for 
the names parameter, particularly given the other parameters are actual lists.

5) I'd like to see the data classes (e.g. Recipe) have actual python 
properties on top of the getter functions, and the rest of the code should 
then use the properties. recipe.pn is a bit neater than recipe.get_pn() 
particularly as the former mirrors usage within the layer index code itself as 
well as tinfoil's TinfoilRecipeInfo (although TinfoilRecipeInfo doesn't 
actually use properties - it probably should - but the usage syntax is the key 
bit).

6) There are a number of different instances of variables "lindex" and they 
are different types. There's even "for lindex in self.lindex". This is a bit 
confusing.

7) What's loadRecipes = 1 for above load_layerindex() ?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre




  reply	other threads:[~2018-07-17 20:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12 20:34 [PATCH 0/5] Add a standard module for accessing the layerindex Mark Hatle
2018-07-12 20:34 ` [PATCH 1/5] bblayers/layerindex.py: Fix addition of layers Mark Hatle
2018-07-12 20:34 ` [PATCH 2/5] layerindexlib: Initial layer index processing module implementation Mark Hatle
2018-07-12 20:34 ` [PATCH 3/5] bblayers/layerindex.py: Switch to use the new layerindexlib class Mark Hatle
2018-07-12 20:34 ` [PATCH 4/5] bitbake-layers: disable parsing for layerindex commands Mark Hatle
2018-07-12 20:34 ` [PATCH 5/5] toaster/orm/management/commands/lsupdates.py: Use new layerindexlib module Mark Hatle
2018-07-12 21:07 ` [PATCH 0/5] Add a standard module for accessing the layerindex Mark Hatle
2018-07-17 20:37   ` Paul Eggleton [this message]
2018-07-17 20:56     ` Mark Hatle
2018-07-18  7:03       ` Paul Eggleton

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=2844607.YnhVh9u1Q8@localhost.localdomain \
    --to=paul.eggleton@linux.intel.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=mark.hatle@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.