From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by mail.openembedded.org (Postfix) with ESMTP id CC48374BEC for ; Tue, 17 Jul 2018 20:56:15 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id w6HKuFUv026994 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2018 13:56:16 -0700 (PDT) Received: from soho-mhatle-m.local (172.25.36.228) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.399.0; Tue, 17 Jul 2018 13:56:14 -0700 To: Paul Eggleton References: <20180712203413.118578-1-mark.hatle@windriver.com> <2844607.YnhVh9u1Q8@localhost.localdomain> From: Mark Hatle Openpgp: preference=signencrypt Autocrypt: addr=mark.hatle@windriver.com; prefer-encrypt=mutual; keydata= xsBNBFYKxFgBCACt/pzutBp6p/xVKTFJjHbM3KpQKCblyot/YP+bpTr51Hrc5xDXBQhoG7TC aIRvRIvbhEevEQK9y04gW3JK/5lobq5ORebolcsHlYBUvpNeIPjupLQwGvz/TPtrLRNGLqDC rvsM6OA2XbQ2bwzxWaSQS3ImE2O2iXOZn9HhThMGeDB4Nff3fgUvXOTDIrgWOn9K2DgLL7Yc zkUIlFdj+Nraksd/7BSk8oH6tjeBVhFqSFvKta9QxWgdr58oPaTYaW/xNqUjlLrbJuMw/MSe xzuYfdfDfm6J8kRjMOnwQ0n8svJElzqAk+d83ow38gpGQ+LkjGgnf8ZFJ4rUJFADroX3ABEB AAHNJU1hcmsgSGF0bGUgPG1hcmsuaGF0bGVAd2luZHJpdmVyLmNvbT7CwHcEEwEIACEFAlYK xFgCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQfv796/r0vvlvZAf9Gs+eN320yhRW V/fZCsngKhmOK4v3HrTwFrkSmoD9QHQiE/5IPdNacHwIPwZx07tNBohB8xOeNqCPRYRBwGhA AnxKOPyd0nnm6ZhPzbA57v4x3IGRQr4QzvcBTASJq91l3Ew4lpAslyx5w1DPPqRD7G8ycDKg peKyDwmdkvCunVisSAQI3XIMq2y230biTO98tDPEezg+lg+yTsz9ZT33F5KNuWrpf8VL5fG/ mt+kAv7wtsx/KTRbqhH3iFXF6eBSwMjAfTXFlkLfbM9riJGXrWEl9n2S2R3cDHNHug0lb8f4 whK370KEO4OwRKIYW/VUBmzk5XZUE9DTlDSV8ycsrs7ATQRWCsRYAQgAwK3FuHCE+HW3YWdH PUjeSn5p//xJ57u8g2rng8zm9zNjmYgpPv5UxozaD9i2jf4mlQLHGGOezhHae8K4Nj70oVcv 8AmwcrJa9i9WL1oy/9R3fHMWf/Ctt9VXTO0qlCuq6PDzaUfvsXR61aJIjTKNQTOjCLjY1vXm VSewUgARysmA8WrjTfwGBihMBxAX0+kIjx8nOlam0WvekMBXZ0AbS56oTLRxYao6DI3GeB/N oWPy/5DfuTKaSdM0Pf8al20x9RuNN5/HLMlyDH/k8bIa1xd9aAqW+Feiw5gC107V2E6ULyIy q6em2UrsmIRxrvpHqbNgQKqvTehJ+V/i4g/uOwARAQABwsBfBBgBCAAJBQJWCsRYAhsMAAoJ EH7+/ev69L755XAH/3ZcNhooqd9OBhFkvXm1iWZ8EoC7motWqVn2oEyxoonsg8AD9kFXiN+T dYp7dH99EZu9q4ptj56AXm4uHzOgywL/5/V2TY6twCGAjUGzDjAB5gzoi+JLIBlDiyOip0eL QswIhRk473xy3j8DA4oVamnSPWgyNJ+qsdt37YWDzoDFFvtDoRU7Eb+znfIMDKzlny0XU/8L cW1bNHJlpv/78GPdfP4tjysEd8MuA5jf5o5w4XqcwTqalffEJtQ/s3pbkstEi7qm5uPui5Kt gq6YYLSqcSNe0GWAF9/T+qwyo7burSTxUWCWtMmlXdAQLW9SynLhB3Jbch0nFAh0fCKi6yY= Organization: Wind River Systems Message-ID: <0caa3638-b5fa-d18a-1776-2ca510f18173@windriver.com> Date: Tue, 17 Jul 2018 15:56:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2844607.YnhVh9u1Q8@localhost.localdomain> Cc: bitbake-devel@lists.openembedded.org Subject: Re: [PATCH 0/5] Add a standard module for accessing the layerindex X-BeenThere: bitbake-devel@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussion that advance bitbake development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:56:15 -0000 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit On 7/17/18 3:37 PM, Paul Eggleton wrote: > 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. That was actually the intent, to treat it as a list. It must have fallen away in a refactor, I'll work to get this fixed. > 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. Behind the scenes the issue is that I expect there to be different plugins that allow data manipulation in similar ways, but with different processing. I was afraid of overriding the URI part, thus added the type field instead. If we can come up with a proper format for this, then I think we could drop the typing.. but what I've come up with so far is that we need: Cooker - data from the local cooker instance restapi-web - knowledge of how to load and parse layerindex-web data restapi-file - a json formatted file with all of the data.. (Note: in this case, it can be one or more files, but everything has to be loaded together) (the web and file stuff are co-mingled right now, maybe that is a mistake... they were put together since for 'offline' work, the web should be able to use a cached file...) Looking at toaster, I could see the need for a 'database' way to store and load it... but I'm not sure that is a good longer term idea. but I'm open to suggestion there to remove the type stuff.. > 3) "except Exception" is too broad, can we catch a specific exception class or > classes instead? This is a mistake in the implementation, the exceptions should have been: LayerIndexError exceptions. (Defined in common.py) > 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. Ok, I will update that. > 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). I'm not sure I understand. You mean something like: class Recipe(LayerIndexItem_LayerBranch): ... self.pn = value so you can do recipe.pn vs recipe.pn() or get_pn()? The reason it's setup the way it is, is to preserve the data in the same format as the layerindex itself. This allows someone to just dump the recipe.data directly, and everything stays in format. Does python have a way to return processed data without it looking like a function call, i.e. with the ()? Is this what __getattr()__ is for? > 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. I was trying to not call everything 'layerindex' every time I used it.. :| Thus lindex.. self.lindex is the list of layerindex objects BTW. The layerindexer can handle more then one collection of objects... (multiple layer indexes specifically). so the for lindex in self.lindex... is for each index in the list of indexes, do... I'll see what I can do about renaming this stuff. > 7) What's loadRecipes = 1 for above load_layerindex() ? Errant paste.. no usage in this. I'll remove it. > Cheers, > Paul >