# Command Guidelines

This document describes the command guidelines for 'az' and applies to both CLI
command modules and extensions.

Guidelines marked (*) only apply to command modules, not extensions.

If in doubt, ask!

[1. General Patterns](#general-patterns)

[2. Command Naming and Behavior](#command-naming-and-behavior)

[3. Argument Naming Conventions](#argument-naming-conventions)

[4. Standard Command Types](#standard-command-types)

[5. Non-standard Commands](#non-standard-commands)

[6. Commands with Complex Types](#commands-with-complex-types)

[7. Network Rule Commands](#network-rule-commands)

[8. Error Handling](#error-handling)

[9. Coding Practices](#coding-practices)

## General Patterns

- Be consistent with POSIX tools (support piping, work with grep, awk, jq, etc.)
- Support tab completion for parameter names and values (e.g. resource names)
- Commands must support all output types (json, tsv, table)
- Provide custom table outputs for commands that don't provide table output
automatically
- Commands must return an object, dictionary or `None` (do not string, Boolean,
etc. types)
- Command output must go to `stdout`, everything else to `stderr`
(log/status/errors).
- Log to `logger.error()` or `logger.warning()` for user messages; do not use the
`print()` function
- Use the appropriate logging level for printing strings. e.g.
`logging.info(“Upload of myfile.txt successful”)` NOT `return “Upload successful”`.

## Command Naming and Behavior

- Commands must follow a "[noun] [noun] [verb]" pattern

- Multi-word subgroups should be hyphenated (e.g. `foo-resource` instead of
`fooresource`)
- All command names should contain a verb (e.g. `account get-connection-string`
instead of `account connection-string`)
- For commands which maintain child collections, the follow pairings are
acceptable.
1. `CREATE`/`DELETE` (same as top level resources)
2. `ADD`/`REMOVE`
- Avoid hyphenated command names when moving the commands into a subgroup would
eliminate the need (e.g. `database show` and `database get` instead of `show-
database` and `get-database`).
- If a command subgroup would only have a single command, move it into the parent
command group and hyphenate the name. This is common for commands which exist only
to pull down cataloging information (e.g. `database list-sku-definitions` instead
of `database sku-definitions list`). However, if you plan to add commands to this
group in the future, then temporarily having a command group with a single command
would make more sense. For example, if you only have `database list` but eventually
plan to support `database create/update/...` then having a `database` group with a
single command would be fine.
- In general, avoid command subgroups that have no commands. This often happens at
the first level of a command branch. For example, `keyvault create` instead of
`keyvault vault create` (where `keyvault` only has subgroups and adds unnecessary
depth to the tree).
<details>
<summary>Click for a full example</summary>
<p>
KeyVault has secrets, certificates, etc that exist within a vault. The existing
(preferred) CLI structure looks like:

```
Group
az keyvault: Safeguard and maintain control of keys, secrets, and
certificates.

Subgroups:
certificate : Manage certificates.
key : Manage keys.
secret : Manage secrets.

Commands:
create : Create a key vault.
delete : Delete a key vault.
delete-policy: Delete security policy settings for a Key Vault.
list : List key vaults.
list-deleted : Gets information about the deleted vaults in a subscription.
purge : Permanently deletes the specified vault.
recover : Recover a key vault.
set-policy : Update security policy settings for a Key Vault.
show : Show details of a key vault.
update : Update the properties of a key vault.
```

To create a vault, you simply use `az keyvault create ...`. An alternative
would be to place the vault commands into a separate subgroup, like this:
```
Group
az keyvault: Safeguard and maintain control of keys, secrets, and
certificates.

Subgroups:
certificate : Manage certificates.
key : Manage keys.
secret : Manage secrets.
vault : Manage vaults.
```

Now, to create a vault, you have to use `az keyvault vault create ...` which is
overly verbose adds unnecessary depth to the tree. The preferred style makes the
command use more convenient and intuitive.
</p>
</details>
## Argument Naming Conventions

- Arguments with specific units:

1. In general, DO NOT put units in argument names. ALWAYS put the expected units
in the help text. Example: `--duration-in-minutes` should simply be `--duration`.
This prevents the need to add more arguments later if more units are supported.
2. Consider allowing a syntax that will let the user specify units. For example,
even if the service requires a value in minutes, consider accepting 1h or 60m. It
is fine to assume a default (i.e. 60 = 60 minutes).
3. It is acceptable to use a unit in the argument name when it is used like an
enum. For example, `--start-day` is okay when it accepts MON, TUE, etc. `--start-
hour` is okay when it indicates an hour of the day.
- ID Arguments:
1. Arguments that end in `-id` should be GUIDs.
2. Arguments that expect ARM IDs should omit `-id` but call out that an ARM ID is
allowed in the help text. These are often used as part of the "name or ID"
convention (i.e: `--storage-account` can often accept a storage account name OR ARM
ID).
- Overloading Arguments:
1. Avoid having multiple arguments that simply represent different ways of
getting the same thing. Instead, use a single descriptive name and overload it
appropriately. For example, assume a command which can accept a parameter file
through a URL or local path.

**AVOID**
```
--parameters-url URL to a parameters file.
--parameters-path Local path to a parameters fle.
```

**PREFERRED**
```
--parameters Local path or URL to a parameters file.`
```

## Standard Command Types

The following are standard names and behavioral descriptions for CRUD commands
commonly found within the CLI. These standard command types MUST be followed for
consistency with the rest of the CLI.

- `CREATE` - standard command to create a new resource. Usually backed server-side

by a PUT request. 'create' commands should be idempotent and should return the
resource that was created.
- `UPDATE` - command to selectively update properties of a resource and preserve
existing values. May be backed server-side by either a PUT or PATCH request, but
the behavior of the command should always be PATCH-like. All `update` commands
should be registered using the `generic_update_command` helper to expose the three
generic update properties. `update` commands MAY also allow for create-like
behavior (PATCH) in cases where a dedicated `create` command is deemed unnecessary.
`update` commands should return the updated resource.
- `SET` - command to replace all properties of a resource without preserving
existing values, typically backed server-side by a PUT request. This is used when
PATCH-like behavior is deemed unnecessary and means that any properties not
specifies are reset to their default values. `set` commands are more rare compared
to `update` commands. `set` commands should return the updated resource.
- `SHOW` - command to show the properties of a resource, backed server-side by a
GET request. All `show` commands should be registered using the `show_command` or
`custom_show_command` helpers to ensure `404(Not Found)` is always returning an
exit code of 3.
- `LIST` - command to list instances of a resource, backed server-side by a GET
request. When there are multiple "list-type" commands within an SDK to list
resources at different levels (for example, listing resources in a subscription
vice in a resource group) the functionality should be exposed by have a single list
command with arguments to control the behavior. For example, if `--resource-group`
is provided, the command will call `list_by_resource_group`; otherwise, it will
call `list_by_subscription`.
- `DELETE` - command to delete a resource, backed server-side by a DELETE request.
Delete commands return nothing on success.
- `WAIT` - command that polls a GET endpoint until a condition is reached. If any
command within a command group or subgroup exposes
the `--no-wait` parameter, this command should be exposed.

## Non-standard Commands

For commands that don't conform to one of the above-listed standard command
patterns, use the following guidance.

- (*) Don't use single word verbs if they could cause confusion with the standard
command types. For example, don't use `get` or `new` as these sound functionally
the same as `show` and `create` respectively, leading to confusion as to what the
expected behavior should be.
- (*) Descriptive, hyphenated command names are often a better option than single
verbs.

## Commands with Complex Types

Certain endpoints accept complex object that themselves contain other complex
objects or collections of complex objects. Since this child resources lack
endpoints of their own, it can often be difficult to craft CLI commands to manage
such objects. The tendency is to simply accept a JSON blob for these arguments.
**THIS PRACTICE IS UNACCEPTABLE.** Existing instances of JSON strings have
demonstrably frustrated customers because (1) the required format is inadequately
(if at all) conveyed, (2) inputting JSON strings on the command line is tedious and
extremely difficult on certain shells, necessitating error-prone escaping and (3)
parsing errors are difficult to troubleshoot.

### Single Complex Parameters

The simplest case is when a complex parameter is a single object with simple
properties. In this case, the simplest approach is to expose the properties of the
complex parameter as individual parameters on the parent resource and then assemble
the complex parameter inside a custom command (most common) or validator.

For example, consider the following structure for an object of type Foo:
```
{
name: str,
type: str,
policy: {
action: enum,
values: list(str)
}
}
```

The custom code would look like:

```Python
def create_foo(cmd, client, name, resource_group_name, type, policy_action,
policy_values):
Foo, Policy = cmd.get_models('Foo', 'Policy')
foo_obj = Foo(
name=name,
type=type,
policy=Policy(
action=policy_action,
values=policy_values
)
)
return client.create_or_update(name, resource_group_name, foo_obj)
```

Best practice would be to group the policy arguments together in help using the
`arg_group` keyword, like so:
```Python
with self.argument_context('foo') as c:
c.argument('name', options_list=['--name', '-n'], ...)

with self.argument_context('foo', arg_group='Policy') as c:

c.argument('policy_action', get_enum_type(Policy), options_list='--action',
help='The policy action to apply.')
c.argument('policy_values', options_list='--values', nargs='+', help='Space-
separated list of policy values to match.')
```

### Collection Management with Commands

Often a resource contains collections of child objects. The simplest way to handle
these situations is to give the complex collection its own command subgroup.
Consider our Foo resource. Let's add a complex collection:
```
{
name: str,
...
rules: [
{
name: str,
metric: enum,
operation: enum,
value: str
},
...
]
}
```

In this case, the most idiomatic and straight-forward solution would be to expose a
group of `rule` subcommands. The foo create command would look like:
```Python
def create_foo(cmd, client, resource_group_name, foo_name, policy_action,
policy_values):
Foo, Policy = cmd.get_models('Foo', 'Policy')
foo_obj = Foo(
rules=[], # if service fails, see: Overcoming Service Limitations
policy=Policy(
action=policy_action,
values=policy_values
 )
)
return client.create_or_update(foo_name, resource_group_name, foo_obj)
```

The corresponding rule create looks like:

```Python
def create_foo_rule(cmd, client, resource_group_name, foo_name, rule_name, metric,
operation, value):
from azure.cli.commands import upsert_to_collection, get_property
FooRule = cmd.get_models('FooRule')
# get the parent object
foo_obj = client.get(resource_group_name, foo_name)
new_rule = FooRule(
name=rule_name,
metric=metric,
operation=operation,
value=value
)
# add the new child to the parent collection
upsert_to_collection(foo_obj, 'rules', new_rule, 'name')
# update the parent object
foo_obj = client.create_or_update(name, resource_group_name, foo_obj).result()
# return the child object
return get_property(foo_obj.rules, rule_name)
```

The usage pattern of this implementation to create two rules would be:
```
az foo create -g MyRG -n myfoo --action allow --values test prod
az foo rule create -g MyRG --foo-name myfoo -n rule1 --metric name --operations
equals --value test
az foo rule create -g MyRG --foo-name myfoo -n rule2 --metric age --operations
lessThan --value 100
```

### Collection Management with Actions

An alternative to using subcommands to manage collections is to assemble complex

objects using argparse Actions. This is acceptable, but is **NOT RECOMMENDED**, for
the following reasons:
1. The UX is much more complicated and potentially confusing for the customer. See
`az monitor action-group create` for an example.
2. The implementation is more complex for the command author/maintainer.
3. There is no mechanism for user-friendly features like tab-completion.

Given that, consider how we could implement the earlier example, this time using
actions on the `foo create` command instead of subcommands to manage the
collection:
```
{
name: str,
...
rules: [
{
name: str,
metric: enum,
operation: enum,
value: str
 },
...
]
}
```

The argument registration would look like:

```Python
with self.argument_context('foo create') as c:
...
c.argument('rules', options_list=['--rule', '-r'], action=FooRuleAddAction,
nargs='+')
```

The rule action will need some way to parse out several arguments from a single
string. There are two ways of doing this. One would be to make the syntax of the
action
use positional arguments. This works well when there is an obvious positional
relationship between the parameters. The other would be to accept key=value pairs.
This will create a much more verbose command string, but may be appropriate when
there's no positional relationship between the arguments. Here is an example of
each.

#### Positional Arguments

```Python
# pylint: disable=protected-access
class FooRuleAddAction(argparse._AppendAction):

def __call__(self, parser, namespace, values, option_string=None):

try:
FooRule = namespace._cmd.get_models('FooRule')
name, metric, operation, value = values.split()
return FooRule(
name=name,
metric=metric,
operation=operation,
value=value
)
except ValueError:
raise CLIError('usage error: {} NAME METRIC OPERATION
VALUE'.format(option_string))
```

The usage pattern of this implementation to create two rules would be:
```
az foo create -g MyRG -n myfoo --action allow --values test prod --rule rule1 name
equals test --rule rule2 age lessThan 100
```

#### Key=Value Arguments

```Python
# pylint: disable=protected-access
class FooRuleAddAction(argparse._AppendAction):

def __call__(self, parser, namespace, values, option_string=None):

FooRule = namespace._cmd.get_models('FooRule')
kwargs = {}
for item in values.split():
try:
 key, value = item.split('=', 1)
kwargs[key] = value
except ValueError:
raise CLIError('usage error: {} KEY=VALUE
[KEY=VALUE ...]'.format(option_string))
return FooRule(**kwargs)
```

The usage pattern of this implementation to create two rules would be:
```
az foo create -g MyRG -n myfoo --action allow --values test prod --rule name=rule1
metric=name operation=equals value=test --rule name=rule2 metric=age
operation=lessThan value=100
```

### Overcoming Service Limitations

There are times when service limitations can interfere with the recommended
approach of handling complex collections using subcommand groups. In our example,
the service might fail if the `foo_create` command supplied an empty rule
collection. This is something we can work around in the CLI using the `--defer`
caching mechanism. The following changes should be made:

In `commands.py`, add the `supports_local_cache=True` kwarg to the command

registration:
```Python
with self.command_group('foo', foo_sdk) as g:
g.custom_command('create', 'create_foo', supports_local_cache=True)
...

with self.command_group('foo rule', foo_sdk) as g:

g.custom_command('create', 'create_foo_rule', supports_local_cache=True)
...
```

Update the custom commands to use the `cached_get` and `cached_put` helpers:
```Python
def create_foo(cmd, client, resource_group_name, foo_name, policy_action,
policy_values):
from azure.cli.core.commands import cached_get, cached_put
Foo, Policy = cmd.get_models('Foo', 'Policy')
foo_obj = Foo(
rules=[],
policy=Policy(
action=policy_action,
values=policy_values
)
)
# cache the payload if --defer used or send to Azure
return cached_put(cmd, client.create_or_update, resource_group_name, foo_name,
foo_obj)
```

The corresponding rule create looks like:

```Python
def create_foo_rule(cmd, client, resource_group_name, foo_name, rule_name, metric,
operation, value):
from azure.cli.core.commands import cached_put, upsert_to_colleciton,
get_property
 FooRule = cmd.get_models('FooRule')
# retrieves the object from the cache. On a miss, retrieves from Azure
foo_obj = cached_get(cmd, client.get, resource_group_name, foo_name)
new_rule = FooRule(
name=rule_name,
metric=metric,
operation=operation,
value=value
)
# add the new child to the parent collection
upsert_to_collection(foo_obj, 'rules', new_rule, 'name')
# re-cache the parent with --defer or send to Azure
foo_obj = cached_put(cmd, client.create_or_update, name, resource_group_name,
foo_obj).result()
# return the child object
return get_property(foo_obj.rules, rule_name)
```

The usage pattern of this implementation to create two rules would be:
```
az foo create -g MyRG -n myfoo --action allow --values test prod --defer
az foo rule create -g MyRG --foo-name myfoo -n rule1 --metric name --operations
equals --value test --defer
az foo rule create -g MyRG --foo-name myfoo -n rule2 --metric age --operations
lessThan --value 100
```

## Network Rule Commands

Several services support the concept of network rules. To drive consistency across
services, command authors for these services should use the following as guidance.
Questions/exceptions should be directed to the CLI team.

- The parent resource should expose a single command group called `network-rule`
with three commands: `add`, `remove`, `list`.
- Internally, network rules are typically modeled as a rule set. This
implementation is largely hidden from the user since these services only allow a
single rule set. If there are properties that can be set on the rule set generally
(the only known one as of this writing is `default_action`, these properties should
be exposed on the `create/update` commands of the parent object, under an argument
group called `Network Rule`.
- The following examples assume that individual rules do not have names. If your
rules do have names, consult the CLI team for guidance.
- The `... network-rule add` command should look similar to the following,
depending on which features are supported by the service.
```
Arguments
--name -n [Required] : The name of the [PARENT RESOURCE].
--resource-group -g : Name of resource group. You can configure the
default group using `az
configure --defaults group=<name>`.

IP Address Rule Arguments

--ip-address : IPv4 address or CIDR range.
--action : Action of the IP rule. Default: Allow

Virtual Network Rule Arguments

--subnet : Name or ID of subnet. If name is supplied, `--vnet-
name` must be
 supplied.
--vnet-name : Name of a virtual network.
--ignore-missing-endpoint : Create the rule before the virtual network has vnet
service
endpoint enabled.
```

- The `... network-rule remove` command should look similar to the following,
depending on which features are supported by the service.
```
Arguments
--name -n [Required] : The name of the [PARENT RESOURCE].
--resource-group -g : Name of resource group. You can configure the
default group using
`az configure --defaults group=<name>`.

IP Address Rule Arguments

--ip-address : IPv4 address or CIDR range.

Virtual Network Rule Arguments

--subnet : Name or ID of subnet. If name is supplied, `--
vnet-name` must be
supplied.
--vnet-name : Name of a virtual network.
```

## Error Handling

Follow the [Error Handling Guidelines](https://github.com/Azure/azure-

cli/blob/dev/doc/error_handling_guidelines.md) to select a proper error type and
write an actionable error message.

## Coding Practices

- All code must support Python 3.6, 3.7 and 3.8

- PRs to Azure/azure-cli and Azure/azure-cli-extensions must pass CI
- Code must pass style checks with pylint and pep8
- (*) All commands should have tests