settings: revisit list options to make all consistent

[beraldoleal]

Today we have some arguments that are defined as list during "registration time", and we might have multiple syntaxes for those, depending on the "key_type". We need to see if there is any standards to follow when the argument is a list, since "--foo ['a', 'b']" is not so usable.

This might create confusion among users because they are not consistent. Some options are using space (--loaders) others are using comma (--show).

BP001 is recommending spaces for lists:

Lists: When an option argument has multiple values we should use the space as the separator.

But, as pointed by @ldoktor in #3439, using spaces as separators might be a problem.

[beraldoleal]

Just to give some background, here 3 "list" examples:

job.run.store_logging_stream

settings.register_option(section='job.run',
                         key='store_logging_stream',
                         nargs='+',
                         help_msg=help_msg,
                         default=[],
                         metavar='STREAM[:LEVEL]',
                         key_type=list)

• Accepts list in config

core.show

stgs.register_option(section='core',
                     key='show',
                     key_type=lambda x: set(x.split(',')),
                     metavar="STREAM[:LVL]",
                     nargs='?',
                     default=set(["app"]),
                     help_msg=help_msg)

• Doesn't accept list in config file

datadir.paths.cache_dirs

default = prepend_base_path('~/avocado/data/cache')
stgs.register_option(section='datadir.paths',
                     key='cache_dirs',
                     key_type=list,
                     default=[default],
                     help_msg=help_msg)

• Accepts list in config file

[ldoktor]

@beraldoleal the reason for using list in --show is that it is a global argument after which the subcommand should come but the parser is not able to tell whether the next argument is another --show argument or the subcommand. Apart from the global arguments avocado should use the usual nargs.

An example:

avocado --show foo bar run ...

the parser can not tell whether run is a show argument or subcommand. For the subcommand arguments we can use -- but this is (at least was) not possible for the global ones.