Proposal: Swappable Publishing

[eyeseast]

We have a bunch of issues dealing with uploading a generated site to other servers: Webfaction #129, Github Pages #110 or elsewhere #244.

I propose splitting out publishing from Tarbell core and creating separate TarbellPublisher subclasses for S3 and other platforms.

Under this proposal:

• Tarbell itself is only responsible for generating a built site, using the existing tarbell generate functionality.
• A TarbellPublisher subclass handles uploading a built site to a remote server. This might be S3, Rackspace CloudFiles, another server via rsync, or even something like a Redis instance (essentially pre-filling a cache).

Assume each platform would have its own subclass and would deal with platform-specific logic. A lot of this is already implemented in tools like invar and aws-cli, so a publisher might only need to wrap an existing tool.

Tarbell would have to detect what kind of publisher to use, based on tarbell_config.py, and would need some way to register publishers. There might be a general publisher setting, or maybe specific settings for deployment targets. In theory, people could register custom publishers (somehow).

Here's one possibility:

# publishing configuration
PUBLISH = {    
    "staging": "rsync://user:password@staging.example.com/project",
    "production": "s3://example.com/project",
}

This would use rsync for a staging target and S3 for production (which would potentially let you password-protect content before it's live).

Under the hood, Tarbell would need to:

1. parse a target URI, routing s3://example.com/project to an S3Publisher
2. generate a static site, as normal, using tarbell generate and putting files in a temp directory
3. run the right publisher to upload built files

Thoughts?

[eads]

One initial thought: FUCK YEAH. This is absolutely part of the roadmap for this year, and I'm glad you're putting some effort into thinking through how it should work.