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
next prev parent 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.