Using ArgparseController without a default command results in an unhandled exception.

Code:

from cement.core.foundation import CementApp
from cement.ext.ext_argparse import ArgparseController, expose


class MyBaseController(ArgparseController):
    @expose(help='<Subcommand description>')
    def subcommand(self):
        self.app.log.info("subcommand successful")


class MyApp(CementApp):
    class Meta:
        label = 'demo'
        handlers = [MyBaseController]


with MyApp() as app:
    app.run()

The help output looks as expected:

> python3 demo4.py --help
usage: demo [-h] [--debug] [--quiet] {subcommand} ...

optional arguments:
  -h, --help    show this help message and exit
  --debug       toggle debug output
  --quiet       suppress all output

sub-commands:
  {subcommand}
    subcommand  <Subcommand description>

But running with no command raises an exception:

> python3 demo4.py
Traceback (most recent call last):
  File "demo4.py", line 18, in <module>
    app.run()
  File "C:\Python34\lib\site-packages\cement\core\foundation.py", line 882, in run
    return_val = self.controller._dispatch()
  File "C:\Python34\lib\site-packages\cement\ext\ext_argparse.py", line 927, in _dispatch
    (contr.__class__.__name__, func_name))      # pragma: nocover
cement.core.exc.FrameworkError: Controller function does not exist MyBaseController.default()

It seems that, if there is no default function, the best thing would be to output a parse error, as if the user had typed in an invalid function.

Otherwise, I take it that the default function is required by cement, in which case a doc update might be appropriate: http://builtoncement.com/2.10/api/ext/ext_argparse.html#cement-ext-ext-argparse

Thoughts?

(Obviously a good workaround is to create a default command and print the help text.)

By having the Meta.label be dynamically fetched when "colorize" is set, one can subclass ColorLogHandler to add further functionality (ie. mailing when a fatal error occurs). Now a subclass Handler can be defined, its own class Meta sets the config_defaults and the original ColorLogHandler receives the config from it.

Issue: #571

A lot of tests have been added over the years which were added only for coverage but not actually asserting anything valuable for testing. Would be helpful to have someone identify those tests, and possibly add at least one assertion to them.

This is a low-priority, good first issue... Please note if you're interested in this issue that it is only relevant to the portland branch (Cement 3) currently (or master once portland is merged).

Hello,

I'm wondering why the commands I've defined, appear as subcommands, instead of "main" commands.

For example, I've defined something like the following:

    @expose(
        help='some help',
        aliases=['alias'],
        arguments=[
            (['args'], dict(action='store', nargs='*')),
        ]
    )
    def some_command(self):
        pass

And, when I execute the application for showing the help, this is how appears:

usage: app [-h] [--debug] [--quiet] {some_command, alias} ...

An app

optional arguments:
  -h, --help            show this help message and exit
  --debug               toggle debug output
  --quiet               suppress all output

sub-commands:
  {some_command, alias}
    some_command (alias) some help

The command invocation works fine; it's just that I was expecting to make the commands appear as in the quickstart.

Many thanks for your work.

ujson is fast json encoder/decoder with same interface as in json, I propose to try import ujson first:

try:
    import ujson as json
except:
    import json

when using colorlog(cement2.6) log messages are not written to the 'log file'(mentioned in the config) when 'level' is set to 'debug' but when level is set to other than 'debug' , messages are written to log file as expected .

Hello, When I use --debug flag, with is also display cement.core debug messages, we dont want that Cement specific log messages.

./my.py --debug

2015-01-14 10:30:13,421 (DEBUG) cement.core.foundation : no cache handler defined, skipping.
2015-01-14 10:30:13,422 (DEBUG) cement.core.foundation : setting up myapp.log handler
2015-01-14 10:30:13,423 (DEBUG) cement.core.handler : merging config defaults from '<cement.ext.ext_logging.LoggingLogHandler object at 0x7fa1a139cf98>' into section 'log.logging'
2015-01-14 10:30:13,424 (DEBUG) myapp : logging initialized for 'myapp' using LoggingLogHandler
2015-01-14 10:30:13,425 (DEBUG) cement.core.foundation : setting up myapp.plugin handler
2015-01-14 10:30:13,427 (DEBUG) cement.ext.ext_plugin : plugin config dir /etc/myapp/plugins.d does not exist.
2015-01-14 10:30:13,428 (DEBUG) cement.ext.ext_plugin : plugin config dir /root/.myapp/plugins.d does not exist.
2015-01-14 10:30:13,429 (DEBUG) cement.core.foundation : setting up myapp.arg handler
2015-01-14 10:30:13,435 (DEBUG) cement.core.foundation : setting up myapp.output handler
2015-01-14 10:30:13,436 (DEBUG) cement.core.foundation : setting up application controllers
2015-01-14 10:30:13,437 (DEBUG) cement.core.hook : running hook 'post_setup' (<function add_handler_override_options at 0x7fa1a25ec6a8>) from cement.core.foundation
2015-01-14 10:30:13,438 (DEBUG) cement.core.hook : running hook 'post_argument_parsing' (<function handler_override at 0x7fa1a19e1ea0>) from cement.core.foundation
2015-01-14 10:30:13,439 (DEBUG) myapp : This is a debug message.
2015-01-14 10:30:13,440 (INFO) myapp : This is an info message.
2015-01-14 10:30:13,441 (WARNING) myapp : This is a warning message.

Is there any simple way to do that?

I would like to add support for conf.d/*.conf files to default config handler.

I need it because I have plugins with multiple handlers and would like to use standard interface.handler config sections in plugin's config files. Current plugin handler takes only first section from plugins.d/pluginname.conf.

Also conf.d more generic and obvious solution for modular application.

I will need some help with English spelling to write good documentation.

Every time I instantiate a new cement application, it cleans cement.core.backend.__handlers__ and cement.core.backend.__hooks__. Considering the following (simple!) code:

from cement.core.foundation import CementApp
from cement.core.interface import Interface
from cement.core import handler
from cement.core import backend

class MyInterface(Interface):
    class IMeta:
        label = 'myinterface'

app1 = CementApp('app1')
handler.define(MyInterface)
app2 = CementApp('app2')
print(MyInterface.IMeta.label in backend.__handlers__)

False will be printed. Quite unexpectedly.

If backend.__handlers__ is truly global object, consider to not clean it on every CementApp instantiation. If it is local to specific CementApp object, consider moving from global containers and use app attributes and methods to work with them.

In apps that heavily rely on logging to the console, having colorized output is very useful. For example:

• INFO => No Color
• WARN => Orange
• ERROR => Red
• Critical => Magenta or maybe just Bold Red

The zope interface concept is outdated and the ABC module is the standard way of creating abstract classes/interfaces. It is supported from 2.6 onwards so there is no incompatibility with cement's supported python versions and it removes the responsibility of maintaining and documenting how the interface works. Moreover, more people are familiar with the ABC module then with your own implementation so it decreases the learning curve greatly. Should we start refactoring?

Hello,

First of all, thank you so much @derks for developing and maintaning cement! I have been using it intensely for a web3 project of mine and I am loving it 💪

That said, I was wondering if there was a way to print the full documentation of all commands. Something like my-app --help but that outputs all of the controllers and subcommands, including their descriptions and arguments, in a structured way.

If this feature does not exist, I am happy to try and make a pull request.

Cheers, Cocco

Help wanted - Packaging and distribution

Need help with packaging and distributing a CLI application built using Cement.

The documentation section on the same is incomplete. Please provide detailed info on packaging and distributing CLI apps.

System Information

• Cement Version: stable/3.0
• Python Version: 3.8
• Operating System and Version: Windows 10

Issue: #611

import os
 import tempfile
 import shutil
+from datetime import datetime
 
 
 class Tmp(object):
@@ -170,7 +171,7 @@ def ensure_parent_dir_exists(path):
     return ensure_dir_exists(parent_dir)
 
 
-def backup(path, suffix='.bak'):
+def backup(path, suffix='.bak', *, add_timestamp=False):
     """
     Rename a file or directory safely without overwriting an existing
     backup of the same name.
@@ -178,6 +179,7 @@ def backup(path, suffix='.bak'):
     Args:
         path (str): The path to the file or directory to make a backup of.
         suffix (str): The suffix to rename files with.
+        add_timestamp(bool): whether to add a timestamp to the backup suffix
 
     Returns:
         str: The new path of backed up file/directory
@@ -194,7 +196,13 @@ def backup(path, suffix='.bak'):
     count = -1
     new_path = None
     path = abspath(path)
+
+    if add_timestamp:
+        timestamp = datetime.now().strftime('%Y-%m-%d-%H:%M:%S')
+        suffix = '-'.join((suffix, timestamp))
+

Flet is a Python library for building GUIs on Google Flutter. Out of the box, Cement can be combined with Flet to build a hybrid application (ex: Using Cement features like config file parsing, cli commands/options, hooks, etc as a foundation for launching the Flet GUI app).

Not sure if an Interface/Handler would make sense here... but would be nice to build documentation and a working example of combining Cement + Flet.

To be changed in Cement 3.2.0.

The framework should be as minimal as possible by default, and setting argument options by default isn't ideal for that. This can still be setup in the project template, however the options in the framework should default to None:

class App(object):
    quiet_argument_options = None
    debug_argument_options = None

Ref:

• https://github.com/datafolklabs/cement/issues/613