linux/poky.git/scripts/lib/argparse_oe.py, branch yocto-4.1.3

scripts: Add copyright statements to files without one

2022-08-12T10:58:01+00:00

Where there isn't a copyright statement, add one to make it explicit. Also drop editor config lines where they were present and add license identifiers as MIT if there isn't one. (From OE-Core rev: deb3ccec53e0bd63bc4235cf2b0d3fc781687361) Signed-off-by: Richard Purdie

meta/lib+scripts: Convert to SPDX license headers

2019-05-09T15:31:55+00:00

This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie

argparse_oe: Add int_positive type

2017-07-21T07:44:25+00:00

Sometimes only expect positive values from cmdline so it's better to filter at parsing cmdline step instead of validate later. (From OE-Core rev: 3ef5b518febd047bf90a0955fa2b9fb78ba6dde5) Signed-off-by: Aníbal Limón Signed-off-by: Richard Purdie

scripts/lib/argparse_oe: also change 'positional arguments' to 'arguments'

2016-05-06T09:31:13+00:00

This aligns with our existing 'optional arguments' to 'options' change, and seems more intuitive for users. (From OE-Core rev: 8a1cd471210e5fb77952f28172084bf6a4fb73e8) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

scripts/lib/argparse_oe: simplify options title change

2016-05-06T09:31:13+00:00

There's no need to iterate over the action groups here, as self._optionals and self._positionals are available. (From OE-Core rev: 408694f4320f3cb52a391e5b927fb8c8ba16c1d2) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

scripts/lib/argparse_oe: show subparser help for unrecognized args

2016-05-06T09:31:13+00:00

As an example, `recipetool create foo bar baz` shows `recipetool: error: unrecognized arguments: bar baz` and then displays the main help, not the help for the create command. Fix by saving the subparser name and using it in parse_args() to look up the subparser. (From OE-Core rev: 7fdaaedf4c63c8d019f03f84e22f9b838ef19aa6) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

scripts/lib/argparse_oe: show self.prog in the error message

2016-05-06T09:31:13+00:00

This aligns our subclassed error() with that in the original class, using _print_message and self.prog. Also add a docstring based on the original. (From OE-Core rev: cf0c5175136966eefde8c0d9aa0679e85779f713) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

scripts/lib/argparse_oe: tweak title above options

2016-02-21T09:32:42+00:00

Naming these as "optional arguments" is perhaps slightly confusing since some of the positional arguments might also be optional; in addition it's rare (though possible) for options to be mandatory - up until recently we had a recipetool option (-o) that was mandatory. It's not perfect, but change it to "options" so it's at least a bit more appropriate. (From OE-Core rev: 55e675de6191bf7eccd26df29189f2a6faa40a20) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool: categorise and order subcommands in help output

2016-02-21T09:32:42+00:00

The listing of subcommands in the --help output for devtool was starting to get difficult to follow, with commands appearing in no particular order (due to some being in separate modules and the order of those modules being parsed). Logically grouping the subcommands as well as being able to exercise some control over the order of the subcommands and groups would help, if we do so without losing the dynamic nature of the list (i.e. that it comes from the plugins). Argparse provides no built-in way to handle this and really, really makes it a pain to add, but with some subclassing and hacking it's now possible, and can be extended by any plugin as desired. To put a subcommand into a group, all you need to do is specify a group= parameter in the call to subparsers.add_parser(). you can also specify an order= parameter to make the subcommand sort higher or lower in the list (higher order numbers appear first, so use negative numbers to force items to the end if that's what you want). To add a new group, use subparsers.add_subparser_group(), supplying the name, description and optionally an order number for the group itself (again, higher numbers appear first). (From OE-Core rev: e1b9d31e6ea3c254ecfe940fe795af44761e0e69) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool: add: allow specifying URL as positional argument

2015-12-28T09:25:14+00:00

Having to specify -f is a little bit ugly when a URI is distinctive enough to recognise amongst the other positional parameters, so take it as an optional positional parameter. -f/--fetch is still supported, but deprecated. (From OE-Core rev: aedfc5a5db1c4b2b80a36147c9a13b31764d91dd) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie