[Openembedded-architecture] Building a common framework for all commands inside the scripts folder

[Ibarra Lopez, Humberto]

Okay, I can make use of scriptutils module for this.

About that code you mentioned that implements some part of this and that it’s going into bitbake, I can make use of it for this part but is there a place where I can track this? Does this code have a bug entry in Bugzilla?

Humberto

From: kergoth at gmail.com [mailto:kergoth at gmail.com] On Behalf Of Christopher Larson
Sent: Saturday, May 14, 2016 3:45 PM
To: Ibarra Lopez, Humberto <humberto.ibarra.lopez at intel.com>
Cc: openembedded-architecture at lists.openembedded.org
Subject: Re: [Openembedded-architecture] Building a common framework for all commands inside the scripts folder


On Sat, May 14, 2016 at 12:46 PM, Ibarra Lopez, Humberto <humberto.ibarra.lopez at intel.com<mailto:humberto.ibarra.lopez at intel.com>> wrote:
I write this because I am working in a few bugs that might be better with a higher implementation. The bugs are #8938<https://bugzilla.yoctoproject.org/show_bug.cgi?id=8938>, #8321<https://bugzilla.yoctoproject.org/show_bug.cgi?id=8321>, #9563<https://bugzilla.yoctoproject.org/show_bug.cgi?id=9563>, #9564<https://bugzilla.yoctoproject.org/show_bug.cgi?id=9564>, #9634<https://bugzilla.yoctoproject.org/show_bug.cgi?id=9634>, #9635<https://bugzilla.yoctoproject.org/show_bug.cgi?id=9635> and #9636<https://bugzilla.yoctoproject.org/show_bug.cgi?id=9636>; the first one is about reorganizing oe-selftest options while the rest are related to refactoring optparse to argparse in other commands.

I have gone through these problems and I noticed that there doesn’t seem to be a common ground in implementing commands in the scripts folder. I mean, some of them use scripts/lib/argparse_oe but not all of them, most of the commands work with subcommands but they have different implementations of this. Even if yocto-bsp and oe-selftest don’t have much in common they can still use the same framework to implement subcommands and argument handling.

What I think would be the best way to go, is to have a command.py inside scripts/lib to handle all of this. This command.py could make use of the already existing scripts/lib/argparse_oe.py. At the end , the goal would be not only to have all python commands in scripts/ to implement command.py but to have solid guidelines; in this way every time someone wants to add a new command in this folder  he/she doesn’t end re-implementing the whole thing again.

Bitbake already does something similar with bitbake/lib/bb/command.py, and even when the scripts folder can’t use the same file, it can pretty much have its own framework that solves its own needs.

About the guidelines part, not sure how to make everyone aware of things like this, there doesn’t seem to be a place that fulfills this need other than the wiki. Unfortunately, not everyone is going to look at the wiki before adding a new command. Probably this requires a different thread to be discussed.
That would be all I had to ask. If a common framework for commands inside scripts folder makes sense we can move forward with it, otherwise I could just go on a solve these defects on a command by command basis. Thanks, and I’ll wait for your opinion on this.

I think this is the entire purpose of the scriptutils python module, it just doesn't have the argument parsing and command bits yet, but afaik that's supposed to hold the bits common to the various scripts.

Beyond that, this doesn't seem like a terrible idea to me, but we need to account for some slightly different use cases between the commands, and we need to account for the fact that at least some of this (specifically, plugin loading, and soon some argparse fixes) is already going into bitbake itself, for use by bitbake-layers, so the scripts in oe-core should start leveraging that once its minimum version is bumped.

--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20160516/529f26f6/attachment-0002.html>