The argument name in the deprecation warning message should use the format "--foo-bar" instead of "foo_bar"

Related command

$ az aks create -g binxi1114 -n binxi111401 --enable-pod-security-policy -c 1
Argument 'enable_pod_security_policy' has been deprecated and will be removed in a future release.
Argument '--enable-pod-security-policy' is in preview and under development.

Extension name (the extension in question)

It’s not an issue to a specific extension. It is a common issue.

Description of issue (in as much detail as possible)

I’m working a PR to deprecate the argument ‘–enable-pod-security-policy’, and I get the message like below. The warning message should be “Argument ‘–enable-pod-security-policy’ has been deprecated and will be removed in a future release.”. Argument 'enable_pod_security_policy' is not good.

$ az aks create -g binxi1114 -n binxi111401 --enable-pod-security-policy -c 1
Argument 'enable_pod_security_policy' has been deprecated and will be removed in a future release.
Argument '--enable-pod-security-policy' is in preview and under development.

---

[jiasli]

It is the designed behavior of knack to show argument_dest in the warning message if deprecation target is not specified:

https://github.com/microsoft/knack/blob/cd590312b9b4ea1402d7a0a76814f6ca4da7fab8/knack/arguments.py#L221-L222

        if deprecate_info:
            deprecate_info.target = deprecate_info.target or argument_dest

To override the enable_pod_security_policy in the warning message, please specify

deprecate_info=c.deprecate(target='--enable-pod-security-policy')

Here is an example from resource command module:

https://github.com/Azure/azure-cli/blob/5b91300bb788d59683461b4570854c41dd8c3659/src/azure-cli/azure/cli/command_modules/resource/_params.py#L390-L391

Another example from vm command module:

https://github.com/Azure/azure-cli/blob/93b5083fe5d60bd29ff37ad3e1b32e8a600d3441/src/azure-cli/azure/cli/command_modules/vm/_params.py#L209-L210

[PramodValavala-MSFT]

@bingosummer Thanks for bringing this up! Looks like that is how it is handled in the knack framework (this code here) but looks like if you use the options_list parameter when defining the argument, it would be as expected.

Nonetheless, I believe showing the argument is not best for customers since that would just be confusing. @yonzhan @jiasli Could you share insights on why the default behavior is so?