Merge branch 'release-0.3'

.travis.yml

@@ -2,9 +2,11 @@ language: python
 
 python:
   - '2.7'
+  - '3.5'
 
 before_install:
   - pip install nose
+  - pip install six
   - pip install coverage
   - pip install coveralls
 
@@ -18,6 +20,7 @@ notifications:
   email:
     recipients:
       - benjamin@bengfort.com
+      - will@willz.org
 
     on_success: change
     on_failure: always

README.md

@@ -178,7 +178,7 @@ This milestone will add Python 3 compatibility as well as new features like Conf
 
 * **tag**: v0.2
 * **deployment**: January 25, 2016
-* **commit**: e2529e6
+* **commit**: [90e2275](https://github.com/bbengfort/commis/commit/90e2275214f23d9da4e9e632df88c052bb890389)
 
 Solidified the Commis library by improving the test suite and the documentation. I've also included a couple of modules that were big helps in the past: a color library that wraps colorama, and a LabelCommand. This is really the official "first" version that I feel is production ready.
 

commis/program.py

@@ -74,9 +74,14 @@ def parser(self):
             apkw = {
                 'description': self.description,
                 'epilog':      self.epilog,
-                'version':     self.version,
             }
             self._parser = argparse.ArgumentParser(**apkw)
+
+            # For Python 3 add version as a default command
+            self._parser.add_argument(
+                '-v', '--version', action='version', version="%(prog)s {}".format(self.version)
+            )
+
         return self._parser
 
     @property

commis/version.py

@@ -19,7 +19,7 @@
 
 __version_info__ = {
     'major': 0,
-    'minor': 2,
+    'minor': 3,
     'micro': 0,
     'releaselevel': 'final',
     'serial': 0,

docs/about.md

@@ -55,7 +55,7 @@ The versioning uses a three part version system, "a.b.c" - "a" represents a majo
 
 * **tag**: v0.2
 * **deployment**: January 25, 2016
-* **commit**: (see tag)
+* **commit**: [90e2275](https://github.com/bbengfort/commis/commit/90e2275214f23d9da4e9e632df88c052bb890389)
 
 Solidified the Commis library by improving the test suite and the documentation. I've also included a couple of modules that were big helps in the past: a color library that wraps colorama, and a LabelCommand. This is really the official "first" version that I feel is production ready.
 

docs/tutorial.md

@@ -39,7 +39,7 @@ $ project
 
 Our primary code base is in the `foo` library, which should hold 99% of the Python code. The only other Python modules in this example that are outside of the `foo` library are `foo-app.py` and `setup.py`. The `foo-app.py` script is the main entry point for our application and is very simple, which we will see shortly. The `setup.py` script is for packaging and distribution via `pip`, which will will also discuss in a bit.
 
-The `foo` package includes a `foo.console` module, which in turn contains a `foo.console.commands` and `foo.console.app` modules. The `app` module will contain a subclass of `commis.ConsoleUtility`, which defines how our console application should behave. The `commands` module will organize our various subcommands, and as you can see, the `build` and `serve` modules are already listed, in which the `build` and `serve` commands will be implemented by extending `commis.Command`. We will discuss the `ConsoleUtility` and `Command` interfaces in detail.
+The `foo` package includes a `foo.console` module, which in turn contains a `foo.console.commands` and `foo.console.app` modules. The `app` module will contain a subclass of `commis.ConsoleProgram`, which defines how our console application should behave. The `commands` module will organize our various subcommands, and as you can see, the `build` and `serve` modules are already listed, in which the `build` and `serve` commands will be implemented by extending `commis.Command`. We will discuss the `ConsoleProgram` and `Command` interfaces in detail.
 
 The `foo-app.py` should be incredibly simple, even though it is the main entry point to the application. In fact, all it should do is import the console utility from `foo.console.app` and execute it, _that's it_. It will pretty much look as follows:
 
@@ -77,15 +77,15 @@ For more details on Python code organization see [“Basic Python Project Fi
 
 ## Creating a Console Utility
 
-The Commis library utilizes a class-based interface for defining console utilities and commands. The primary usage is to subclass (extend) both the `ConsoleUtility` and the `Command` class for your purposes, however this is not required. In fact, given two commands, you could easily build a console utility as follows:
+The Commis library utilizes a class-based interface for defining console utilities and commands. The primary usage is to subclass (extend) both the `ConsoleProgram` and the `Command` class for your purposes, however this is not required. In fact, given two commands, you could easily build a console utility as follows:
 
 ```python
 #!/usr/bin/env python
 
-from commis import ConsoleUtility
+from commis import ConsoleProgram
 from foo.console.commands import BuildCommand, ServeCommand
 
-app = ConsoleUtility(
+app = ConsoleProgram(
     description='my foo app',
     epilog='postscript',
     version='1.0'
@@ -95,7 +95,7 @@ app.register(ServeCommand)
 app.execute()
 ```
 
-The `ConsoleUtility.register` command takes a `Command` subclass, and registers it to the console utility, building the necessary parser and subparser classes that the `argparse` module requires. You cannot add a command to a console utility without calling `register`. While the register method is easy, it does not allow you to manage, extend, or reuse the utility for different purposes. Instead, I recommend extending `ConsoleUtility` and modifying it as follows.
+The `ConsoleProgram.register` command takes a `Command` subclass, and registers it to the console utility, building the necessary parser and subparser classes that the `argparse` module requires. You cannot add a command to a console utility without calling `register`. While the register method is easy, it does not allow you to manage, extend, or reuse the utility for different purposes. Instead, I recommend extending `ConsoleProgram` and modifying it as follows.
 
 ```python
 # foo.console.app
@@ -104,15 +104,15 @@ The `ConsoleUtility.register` command takes a `Command` subclass, and registers
 import foo
 
 from commis import color
-from commis import ConsoleUtility
+from commis import ConsoleProgram
 from foo.console.commands import *
 
 COMMANDS = [
     BuildCommand,
     ServeCommand,
 ]
 
-class FooApp(ConsoleUtility):
+class FooApp(ConsoleProgram):
 
     # A description and epilog with colors!
     description = color.format("my foo app", color.CYAN)

tests/__init__.py

@@ -23,7 +23,7 @@
 ## Module Constants
 ##########################################################################
 
-TEST_VERSION = "0.2" ## Also the expected version onf the package
+TEST_VERSION = "0.3" ## Also the expected version onf the package
 
 ##########################################################################
 ## Test Cases

tests/program_tests.py

@@ -18,16 +18,21 @@
 ##########################################################################
 
 import sys
+import six
 import argparse
 import unittest
 
-from cStringIO import StringIO
 from commis.command import Command
 from commis.command import DefaultParser
 from commis.program import handle_default_args
 from commis.program import ConsoleProgram
 from commis.exceptions import ConsoleError
 
+try:
+    from cStringIO import StringIO
+except ImportError:
+    from io import StringIO
+
 try:
     from unittest import mock
 except ImportError:
@@ -133,7 +138,7 @@ def read(self, stream):
         """
         Returns the contents of the StringIO specified.
         """
-        if isinstance(stream, basestring):
+        if isinstance(stream, six.string_types):
             stream = {
                 'stdout': sys.stdout,
                 'stderr': sys.stderr,