From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] applied: [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity
Date: Mon, 31 Aug 2020 12:25:30 +0200 [thread overview]
Message-ID: <1598869361.dwsp40muwa.astroid@nora.none> (raw)
In-Reply-To: <09aabb56-d417-79fc-e0f7-a42d5ec56258@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
prev parent reply other threads:[~2020-08-31 10:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-26 19:27 [pve-devel] " Thomas Lamprecht
2020-08-27 4:22 ` Dietmar Maurer
2020-08-27 6:39 ` Thomas Lamprecht
2020-08-27 7:54 ` Fabian Ebner
2020-08-27 8:54 ` [pve-devel] applied: " Thomas Lamprecht
2020-08-31 10:25 ` Fabian Grünbichler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1598869361.dwsp40muwa.astroid@nora.none \
--to=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox