5dollarwhitebox.org - theboxownsyou

The latest version of the Cement CLI Application Framework for Python has been released. This update includes the following changes:

### Bug Fixes
 
Issue #52 - log_to_console seems to disable all console output
 
Issue #53 - IndexError in cement.core.testing.simulate()
 
Issue #54 - register_hook() decorator does not return the original func
 
Issue #57 - ArgumentError references wrong command name
 
Issue #61 - Set default ‘next’ version in paster templates
 
 
### Feature Enhancements
 
Issue #58 - Setup a BaseController(CementController) on pasted apps Note that this is not used by pasted plugins by default for backward compatibility reasons.
 
Issue #63 - Cleanup application imports
 
 
### Misc Changes
 
Pasted applications now include ./doc with already populated Sphinx documentation (Thanks to Steve Steiner for contributing the initial phase of that).

This week I have had the pure pleasure of updating two small applications that I wrote nearly 5 years ago. What is even more awesome about that is, these were my two very first python applications I ever wrote. Needless to say, both are complete crap. At the time, I really did try and make them 'clean'... but not being very experienced yet I obviously had a lot to learn via trial and error. The code isn't all bad, it is more the structure and design of the applications that are really driving me crazy right now. Not only that, but I of course didn't bother to COMMENT or add UNIT TESTING.

This isn't anything new, just thought I would post something here to be able to link to in the future. We had a brief discussion at work a moment ago about 'how best to execute a shell command in python'. There are dozens of ways... os.system, the commands module, Popen, subprocess, etc. As many know, the commands module is deprecated and subprocess was implemented to replace the others.

That said, how do we execute a shell command via subprocess and get back stdout, stderr, and the returncode?

The latest stable version of Cement 0.8.10 is now available. This update includes:

 +  Application config file now override plugin configs
 +  Added 'core.handlers' module which includes 'define_handler', and 
    'register_handler'.  
 +  Re-factored output rendering.  Output is now handled by 'output_handler' 
    in the config, overridden by @expose(), and overridden by 
    output_handler_override.  
 +  Add 'output_handler_override' to config
 +  Add the ability to pass 'version' to lay_cement, avoiding a dependency
    on pkg_resources.get_distribution

For the next iteration of my on going blog category of wtf-is-going-on-behind-the-scenes-of-turbogears, I found myself exploring the black magic of '@require', and 'repoze.what.predicates'.

The issue arose after nuking my virtualenv for a project, and reinstalling all dependencies fresh.. meaning that of course, something would be updated to a new version... and my application would be broken. Sure enough, the behavior of the following seemed to be different:

@require(predicates.has_permission('admin')
def some_method(self, *args, **kw):
    pass

The latest version of Cement is now released. This is primarily a bug fix and cleanup release including the following changes:

 -  Added a fix for logging.  Previously, an application using a shared
    plugin (such as from Rosendale) would be unable to log because there
    were no handlers setup for the providers module name space.
 -  core.controller.run_controller_command() now requires cli_opts/cli_args
    to be passed *not* as kwargs (potential incompatible change for any
    code using run_controller_command directly).

I came across something at work that made me interested enough to put this together, and I wasn't able to find anything that really suited my needs. The following is a simple bit of code that allows you to pass in a string, and receive back a list of Military Phonetic translations:

phonetics = {
    'a' : 'alfa',
    'b' : 'bravo',
    'c' : 'charlie',
    'd' : 'delta',
    'e' : 'echo',
    'f' : 'foxtrot',
    'g' : 'golf',
    'h' : 'hotel',
    'i' : 'india',
    'j' : 'juliett',
    'k' : 'kilo',
    'l' : 'lima',
    'm' : 'mike',
    'n' : 'november',

It has been a while since I felt inclined to put my face through a wall, and endure physical pain rather than be defeated yet another hour (or day) on a Python/TurboGears road block. Well, over the last few days I have been stumped by self-referential relationships in SQLAlchemy. For those not familiar, this is a simple yet common scenario where a Model has a parent or child of itself that is the same Model. For example:

The latest stable release of Cement has been pushed to PyPi and is now available for installation and upgrade. This is mostly a bug fix and clean up release, and includes the following changes:

 +  Enable passing output to a file rather than STDOUT (GH#20)
 +  Support engine:template mix from @expose()
 +  Namespace get_config() returns ConfigObj object (as is documented)
 +  Set all namespace's config options per cli options (if they have the key)
    regardless of what namespace is called.  I.e. If --myoption is passed to
    a command in the 'mynam' namespace, mynam.config['myoption'] is set as well
    as any other namespace that has that config key.
 +  log.warn on OptionConflictError
 -  Don't render genshi output if --quiet is passed
 -  Resolve GH#6 Make plugin templates pass full version, required_cement_api,
    etc when registering their namespace
 -  Resolve GH#27 Remove unused app_basepath from config templates

Hack onward!

Two days. Two days of banging my head against a wall trying to figure out the simplest of issues. "How do I modify request.environ before controller dispatch"? Why would you want to do that you ask. Well, it started with my last article API Key [Token] Based Authentication in TurboGears 2.1. In it I described my quest to enable token/key based authentication, of which I was successful... but ne'r did I think I would be forced to revisit the issue.