[Core] Configurable CLI Support

[kairu-ms]

Description

This PR is for configurable CLI supporting. The core are modified in the following tree aspects:

• Reconstruction AzCommandGroup
• Add placeholder decorators for properties used in command definition
• Decorate those properties defined in cli code

Reconstruction AzCommandGroup

• Add add_cli_command function in AzCommandsLoader, which supports to register a command in command table by CommandOperation. Reduce the usage of _cli_command fucntion.
• Replace default default_command_handler default_arguments_loader and default_description_loader in _cli_command by CommandOperation
• Replace _cli_generic_update_command by GenericUpdateCommandOperation
• Replace _cli_wait_command by WaitCommandOperation
• Replace _cli_show_command by ShowCommandOperation

Placeholder Decorators

• action
  • cls_action_wrapper
  • cls_action_factory_wrapper
• arg_type
  • register_arg_type
  • arg_type_factory_wrapper
• client_factory
  • func_client_factory_wrapper
• completer
  • func_completer_wrapper
  • completer_factory_wrapper
• exception_handler
  • func_exception_handler_wrapper
• resource_type
  • register_custom_resource_type
• transformer
  • func_transformer_wrapper
• type_converter
  • func_type_converter_wrapper
  • func_type_converter_factory_wrapper
• validator
  • func_validator_wrapper
  • validator_factory_wrapper

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

• I adhere to the Error Handling Guidelines.

[yonzhan]

Core

[jiasli]

The word Operation seems redundant to me and makes the functionality difficult to understand. BaseCommand should suffice in my opinion.

[jiasli]

In my opinion, decorators like these are too intrusive. They extract information from Azure CLI dynamically during runtime.

If I were you, I would statically parse source code files like _params.py with regex or string operation.

[jiasli]

I agree and like this refactoring. The original code is obviously abusing closure and makes the code difficult to read. #Resolved

[jiasli]

But still, even in closure, the values can be retrieved using inspect.getclosurevars(func). #WontFix

[jiasli]

The outer function name can be retrieved using __qualname__ following PEP 3155:

import inspect


def get_printer(msg):
    def printer():
        print(msg)
    return printer


p = get_printer("Hello")
print(p.__qualname__)
print(inspect.getclosurevars(p))

Output:

get_printer.<locals>.printer
ClosureVars(nonlocals={'msg': 'Hello'}, globals={}, builtins={'print': <built-in function print>}, unbound=set())

This can eliminate the necessity of these decorators.

[kairu-ms]

Thanks for your advice. This is a good solution to retrieve data from outer function. But I still prefer decorators because them build a layer between command definitions and linked functions in architecture level, which can not only solve questions above but also bring more flexibility.

[kairu-ms]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[kairu-ms]

Break down to small PRs:

• AzCommandGroup Refector