owmeta_core.cli module¶
- owmeta_core.cli.main(*args)[source]¶
Entry point for the command line interface.
Additional sub-commands can be added by specifying them in an entry point in your package’s setup.py like this:
'owmeta_core.commands': [ 'subcommand_name = module.path.for:TheSubCommand', 'sub.sub.subcommand_name = module.path.for:TheSubSubSubCommand', ],
Where,
subcommand_name
will be the name of the sub-command under the top-levelowm
command andmodule.path.for.TheSubCommand
will be the class implementing the command. To add to existing sub-commands one indicate the place in the command hierarchy as insub.sub.subcommand_name
:TheSubSubSubCommand
would be available under the (hypothetical) existingowm sub sub
command asowm sub sub subcommand_name
So-called “hints” can affect the way command implementations are interepreted such as indicating whether a method argument should be read in as a positional argument or an option and what a command-line option should be named (as opposed to deriving it from a parameter name or member variable). There is a set of hints which are a part of owmeta-core (see
CLI_HINTS
), but these can be augmented by specifying entry points like this:'owmeta_core.cli_hints': 'hints = module.path.for:CLI_HINTS',
If
module.path.for.CLI_HINTS
is a dictionary, it will get added to the hints, potentially affecting any sub-commands without hints already available. The entry point name (hints
in the example) is only used for error-reporting by this module. Although this is not strictly enforced, adding hints for sub-commands published by other modules, including owmeta-core, should be avoided to ensure consistent behavior across installations. Seeowmeta_core.cli_hints
source for the format of hints.See
CLICommandWrapper
for more details on how the command line options are constructed.- Parameters
- *args
Arguments to the command. Used instead of
sys.argv