args, key=value pairs and task yaml

Ralph Bean rbean at redhat.com
Wed Feb 5 10:43:16 UTC 2014


On Tue, Feb 04, 2014 at 02:02:42PM -0700, Tim Flink wrote:
>  ---- SNIP ----
>
> What I'm looking to decide is whether we really need args in addition to
> of key=value pairs and if the added complexity is worth it.
> 
> I propose that we alter the format to use only key=value pairs which
> would be parsed into a dict in the runner. Using the same example as
> above, the new action would look something like:
> 
> ------------------------------------------------------------
> Execution:
>     python: pyfile=runtask.py method_name=do_something action=fix
> ------------------------------------------------------------
> 
> This would simplify the parsing code and the data passing logic for
> execution since all input data would be in the form of a dictionary
> instead of separated out into a list/string and a dictionary.
> 
> While I slightly prefer the aesthetics of allowing one or more
> keyless args in an action instead of all key=value pairs, I can't think
> of a use case where restricting input to key=value pairs would cause
> problems.
> 
> If we do decide that keyless args are needed, I'd rather support more
> than one instead of the current arbitrary restriction of just one arg.
> 
> Any other thoughts?
> 
> Tim

How about something like this:

------------------------------------------------------------
Execution:
    python:
        file: runtask.py
        method: do_something
        args:
        - first_positional_arg
        - second_positional_arg
        kwargs:
            action: fix
------------------------------------------------------------

It takes many more lines to express a task, but the indentation shows
structure and it is much more flexible.  Perhaps it is overkill?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140205/9bb9fd5d/attachment.sig>


More information about the qa-devel mailing list