Custom Errors and Unit tests

• PipelineNotFoundError and PyModuleNotFoundError added
• Red colour on exception bug - reset to normal terminal colour after error print done so subsequent cmds not also in red
• unit tests

Breaking change: What's my --name?

• the cli now takes --name as default. instead of pypyr --name mypipe it's pypyr mypipe
• log level defaults to INFO
• signal interrupt handled (ctrl + c)
• stderr output red

custom errors

• Add custom errors definitions to pypyr
• Not particularly in use in the core (yet), but the plug-ins are using them
• Version increase for new patch release

Assert validator signature changes

• asserts_keys_have_values(self, keys, caller) is now assert_keys_have_values(self, caller, *keys)
• add pypi version badge to readme

The new Context: minor release breaking changes

• Context is now a class with useful helpers, subclassed from Dict. Didn't go whole hog on a full-on MutableMapping implementation, since the goal is to add to Dict, not override anything particular to Dict.
  get rid of the old "static" "helper" class validations that operated on context - these are now on Context itself
  change throughout to use new Context methods
  • The old 'context' package renamed 'parser'. Parser is more descriptive for what these things actually do (they parse stuff, they're not the context itself)
    change throughout where code referenced the old namespace
• yamlfile in parser added
• echo now uses interpolated string
• minor "undocumented functionality" fix to avoid double error when context_parser fails
• add env step for set, get and unset env variables

cd release from shippable

• this release uses shippable to tag release and push tags to master.

Simplify logging

Use built in python logging inheritance. Steps only need to use python logging.getLogger() henceforth.

Breaking change - pipeline step signature change

• From now on a pipeline context is always a dictionary. Simple is better than complex.
• a pipeline step's def run_step(context) used to require a return type return context. This is a hang-over from the early days of pypyr where I was still thinking that a context could by anything - a plain old string, or a dictionary, or a stream (file-like objects in pythonese), or a whatever.
  • So if the run_step(context) was to be an immutable type (e.g a string), then any alterations to the context inside the run_step wouldn't have made it back out of the func unless explicitly returned as a new obj return mymanipulatedblah. Hence the 1st design with the explicit return required.
  • Given the heavy preponderance of mutable dictionary usage for the context for pretty much everything, and given that the dictionary-like context can contain any of the different types listed above (plain old string, dictionary containing dictionaries, dictionary containing lists, or file-like objs), I'm having a hard-time justifying the extra effort to deal with the vague theory that "just maybe" someone just wants to use a plain string as a context for the entire pipeline beginning to end.
  • It also feels gnarly for the end-user to have to remember to have a return context at the end of his custom pipeline step code. There should be one-- and preferably only one --obvious way to do it.

Minor edit of short description on pypi

v0.1.1

Bump version: 0.1.0 → 0.1.1

Promote to v0.1.0

Bump version: 0.0.11 → 0.1.0