Re: [pve-devel] applied: [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On August 27, 2020 10:54 am, Thomas Lamprecht wrote:
> On 26.08.20 21:27, Thomas Lamprecht wrote:
>> If we run out of passed arguments from the user but still had defined
>> "arg_params" (those params which went after the command in fixed
>> order without option -- dashes) we always errored out with "not
>> enough arguments". But, there are situations where the remaining
>> arg_params are all marked as optional in the schema, so we do not
>> need to error out in that case.
>> 
>> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
>> ---
>> 
>> A prime (future) use case is "pvesm prune-backups". Currently the
>> usage is:
>>> pvesm prune-backups storeid --prune-backups keep-last=1,keep-...
>> 
>> Because the "prune-backups" keep retention property is optional as it
>> can fallback to the one defined in the storage configuration.
>> With this patch we can make it an argument and allow the following
>> two usages:
>> 
>> 1. As above, but avoiding the extra ugly --prune-backups
>>> pvesm prune-backups storeid keep-last=1,keep-...
>> 
>> 2. Fallback to storage config:
>>> pvesm prune-backups storeid
>> 
>>  src/PVE/JSONSchema.pm | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>> 
>>
> 
> 
> while Dietmars proposal to move the example above to another format,
> more similar to the one from proxmox-backup, is better; this is still
> nice to have, so: applied

we probably also want this for the else branch (when all arguments are 
optional and none are given), if just for consistency. one example: 'qm 
rescan' could move from 'qm rescan [--vmid VMID] [..]' to 'qm rescan 
[VMID] [..]'. the doc generator seems to handle that correctly already, 
so maybe we even already have cases where the docs indicate optionality 
but the schema does not allow it? :-P