This is a pre-production deployment of Warehouse. Changes made here affect the production instance of PyPI (pypi.python.org).
Help us improve Python packaging - Donate today!
Project Description

Generic backend system to use throughout Armstrong

Usage

Dynamically load a Python module at runtime and use it as if you’d hardcoded the module directly. This allows flexibility. It’s polymorphism in action.

Why? In the Armstrong internals we do a bunch of stuff via backends. If you want to do that stuff differently, make a class with the same interface and provide your class as the backend. Armstrong will work its magic the way you want. In many cases, Armstrong ships with support for multiple common scenarios (implemented as backends) and you can pick the one that fits your needs.

Following the Django paradigm, create a key = value in setttings.py where the value is a string or a list of strings of full, dotted, Python import paths. That module will be imported at runtime and used exactly as if you had instantiated it directly. An example:

# hello/world.py
class Hello(object):
    def hi(self):
        print("Hello world!")

# hello/armstrong.py
class Hello(object):
    def hi(self):
        print("Hello Armstrong!")

# settings.py  <-- armstrong.utils.backends uses Django settings by default
HELLO_CLASS = "hello.armstrong.Hello"

# somewhere_else.py or in a console
>>> from armstrong.utils.backends import GenericBackend
>>> hello = GenericBackend("HELLO_CLASS").get_backend()
>>> hello.hi()
Hello Armstrong!

A default can be provided and the process works like the standard Python dict.get() where if the key doesn’t exist in the settings, there’s a fallback. (This is how Armstrong specifies its defaults so you aren’t required to change your settings.py if satisfied with the default behavior.):

>>> backend = GenericBackend("MISSING_KEY", defaults="hello.world.Hello")
>>> hello = backend.get_backend()
>>> hello.hi()
Hello world!

Calling get_backend() is the equivalent of instantiation. So whenever you’re ready to use the dynamically loaded class, call get_backend. Pass in any parameters you’d normally use. Think of it as __init__. These are the same:

GenericBackend("HELLO_CLASS").get_backend(1, two=2)
Hello(1, two=2)

You can pass in a different settings module with the settings kwarg if you want the backend loader to look somewhere other than Django settings.

Multiple backends

Another powerful feature? Feeding in multiple possible backends. Armstrong will perform the action you want by going down the list of backends stopping at the first one that does its job. If the backend’s method raises a BackendDidNotHandle exception, Armstrong will try the next backend. A pseudo code example:

default_backends = ["myapp.backends.TwitterBackend",
                    "myapp.backends.FacebookBackend"]
backend = GenericBackend("SOCIAL_NETWORKS", defaults=default_backends)

# myapp.backends.py
class TwitterBackend(object):
    def post(msg):
        if not self.user.has_account:
            raise BackendDidNotHandle("No account for that user")

social_network = backend.get_backend(user)
social_network.post("Armstrong is pretty sweet you guys")

Writing Backends

Backends are classes. GenericBackend is a way to dynamically load those classes. Beyond using get_backend to handle the creation of the backend, you treat it as if you were calling it directly.

If you are using multiple backends, all attributes (and methods) accessed on the backend are proxied to handle the dispatching. To have a backend abdicate and have the loader use the next backend in the list, have the backend method raise armstrong.utils.backends.BackendDidNotHandle.

Installation & Configuration

Supports Django 1.3, 1.4, 1.5, 1.6, 1.7 on Python 2.6 and 2.7.

  1. pip install armstrong.utils.backends

Contributing

Development occurs on Github. Participation is welcome!

  • Found a bug? File it on Github Issues. Include as much detail as you can and make sure to list the specific component since we use a centralized, project-wide issue tracker.
  • Testing? pip install tox and run tox
  • Have code to submit? Fork the repo, consolidate your changes on a topic branch and create a pull request. The armstrong.dev package provides tools for testing, coverage and South migration as well as making it very easy to run a full Django environment with this component’s settings.
  • Questions, need help, discussion? Use our Google Group mailing list.

State of Project

Armstrong is an open-source news platform that is freely available to any organization. It is the result of a collaboration between the Texas Tribune and Bay Citizen and a grant from the John S. and James L. Knight Foundation. Armstrong is available as a complete bundle and as individual, stand-alone components.

Release History

Release History

1.1.1

This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.1.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.0.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.2.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.1.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.1.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
armstrong.utils.backends-1.1.1.tar.gz (9.2 kB) Copy SHA256 Checksum SHA256 Source Sep 8, 2014

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting