Add hook system to Tarbell commands

[eads]

Creating of a ~/.tarbell/hooks.py file that can accomodate pre/post command hooks to run (e.g. to allow custom linting on site generation or custom repo setup on new project creation).

[eads]

Added to beta-4 milestone. @rnagle is assigned but we need @alexbordens @aepton @hbillings and the whole team's input ...

[eads]

~/.tarbell/hooks.py is a terrible idea. I have a better one but it needs some details worked out.

Tarbell smooshes together _base/base.py and tarbell_config.py when previewing or building a project. So it seems simple enough to be able to declare hooks in both of those files.

Before we get into more of the mechanics, here's key the hooks I think we need:

• Post-newproject: E.g. create tickets and a repository.
• Pre-generate: E.g. set up default context.
• Post-generate: E.g. upload to your favorite CDN.
• Pre-publish: E.g. gzip or build out assets
• Post-publish: E.g. clear out Facebook opengraph cache

My current best guess at what this should look like is that there should be a @tarbell_hook decorator available in both base.py and tarbell_config.py. Hooks would be explicitly configured in tarbell_config.py, but all the base hooks would automatically be included.

base or tarbell_config:

@tarbell_hook("newproject")
def create_repo(project):
    # ... interact with github or unfuddle to create repo

tarbell_config:

TARBELL_HOOKS = [
   'base.create_repo',
   'base.create_tickets',
   'config.do_crazy_project_specific_thing',
]

[eads]

Paging @rnagle paging @hbillings I need feeeedback on this... I even have a good use case right now from a current internal project.

When publishing to s3, we need to iterate over content in the spreadsheet and for each row (which represents an element in a listicle) create a stub page, a redirect on amazon s3, and finally ping the Facebook opengraph debugger so that each item can be shared individually and seamlessly.

[hbillings]

This sounds logical to me. Question: Why in both tarbell_config and in _base? Just so you can add your own in tarbell_config? Or only enable the ones you want to use?

[eads]

That's an excellent question. One reason would simply be being consistent -- there's a common try tarbell_config.py -> fall back to base.py pattern in Tarbell. You pretty much answered your own question -- I think a good architecture is:

• Default hooks (via base template)
• Project hooks (e.g. handle weird social media needs for just one project)
• Ability for a project to specify what hooks to run in case the base template has something you don't need or want.