Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

Compysition
========

What?
-----
::

A Python application framework to build and manage asynchronous and highly concurrent event-driven data flow

I have created **compysition** to build off the simple way in which Wishbone_ managed message flow across multiple
modules. Compysition expands upon this module registration method to provide abstracted multi-process communication
via 0mq_, as well as the ability for full cyclical communication for in-process request/response behavior in a lightweight,
fast, and fully concurrent manner, using gevent_ greenlets and concurrency patterns to consume and output events

.. _0mq: http://zeromq.org/
.. _Wishbone: https://github.com/smetj/wishbone
.. _gevent: http://www.gevent.org

**Compysition is currently new and in pre-Beta release. It will be undergoing many deep changes in the coming months**
The **compysition** project is built upon the original work of the Wishbone_ project

Variations from the traditional Actor Model
-----

The traditional and strict actor model requires that all actors have exactly one inbox and one outbox. I found that this was
overly constraining for creating and crafting complex data flow models. So compysition inherently supports multiple inboxes
and multiple outboxes on every single actor.

To put it in actor model terms, every actor is also a "funnel" and a "fanout".

The default behavior, unless stated otherwise in the module documentation, is that all modules will send/copy an event to ALL
connected outbox queues

Full Circle WSGI Example
-------

For the example below, we want to execute an XML transformation on a request and send it back to the client in a fast
and concurrent way. All steps and executions are spun up as spawned greenlet on the router

.. code-block:: python

from compysition import Director
from compysition.module import WSGI
from compysition.module import BasicAuth
from compysition.module import Transformer

from mymodules.module import SomeRequestExecutor
from myprojectresources import my_xsl_files as xsls

director = Director()
wsgi = director.register_module(WSGIServer, "wsgi")
auth = director.register_module(BasicAuth, "auth")
submit_transform = director.register_module(Transformer, "submit_transform", xsls['submit'])
acknowledge_transform = director.register_module(Transformer, "acknowledge_transform", my_xsl_files['acknowledge.xsl'])
request_executor = director.register_module(SomeRequestExecutor, "request_executor")

director.connect(wsgi, auth)
director.connect(auth, submit_transform)
director.connect_error(auth, wsgi) # Redirect auth errors to the wsgi server as a 401 Unaothorized Error
director.connect(submit_transform, request_executor)
director.connect_error(submit_transform, wsgi)
director.connect(request_executor, acknowledge_transform)
director.connect(acknowledge_transform, wsgi)

director.start()

Note how modular each component is. It allows us to configure any steps in between class method executions and add
any additional executions, authorizations, or transformations in between the request and response by simply
adding it into the message execution flow

One-way messaging example
-------

.. code-block:: python

from compysition import Director
from compysition.module import TestEvent
from compysition.module import STDOUT

director = Director()
event_generator = director.register_module(TestEvent, "event_generator", interval=1)
output_one = director.register_module(STDOUT, "output_one", prefix="I am number one: ", timestamp=True)
output_two = director.register_module(STDOUT, "output_two", prefix="I am number two: ", timestamp=True)

director.connect(event_generator, [output_one, output_two])

director.start()

Output:
[2015-02-13 16:56:35.850659] I am number two: test
[2015-02-13 16:56:35.850913] I am number one: test
[2015-02-13 16:56:36.851588] I am number two: test
[2015-02-13 16:56:36.851856] I am number one: test
[2015-02-13 16:56:37.852456] I am number two: test
[2015-02-13 16:56:37.852737] I am number one: test
[2015-02-13 16:56:38.858107] I am number two: test
[2015-02-13 16:56:38.858400] I am number one: test
[2015-02-13 16:56:39.860292] I am number two: test
[2015-02-13 16:56:39.860570] I am number one: test

ZeroMQ MajorDomo Implementation Example
-------
The following example is a single-process example of the multi-process MajorDomo Protocal from ZMQ. The pieces noted
could all be run outside this process in their own compysitionscript, scalable across multiple hosts and cores

.. code-block:: python

from compysition.module import MDPClient, MDPWorker, MDPBroker, WSGI, MDPBrokerRegistrationService, STDOUT, Data
from compysition import Director

director = Director()

mdp_client = director.register_module(MDPClient, "mdp_client")
mdp_broker = director.register_module(MDPBroker, "mdp_broker") # This could be it's own process
mdp_regservice = director.register_module(MDPBrokerRegistrationService, "mdp_regservice") # This could be it's own process
mdp_worker = director.register_module(MDPWorker, "mdp_worker", "test_service") # This (These) would be their own processes
stdout = director.register_module(STDOUT, "stdout")
data = director.register_module(Data, "data", data="Hello, this has been a test")

wsgi = director.register_module(WSGI, "wsgi", run_server=True, address="0.0.0.0", port=7000)
director.register_log_module(STDOUT, "stdoutmodule", timestamp=True)

director.connect(wsgi, mdp_client)
director.connect(mdp_worker, data)
director.connect(data, mdp_worker)
director.connect(mdp_client, wsgi)

director.start()

After running this process, initiating a http request to http://127.0.0.1:7000/test_service would show the dataflow across MDP components

Installing
----------

Through Pypi:

$ pip install compysition

Or the latest development branch from Github:

$ git clone git@github.com:fiebiga/compysition.git

$ cd compysition

$ sudo python setup.py install

Support
-------

You may email myself at fiebig.adam@gmail.com

Metadata

Release files for compysition 1.1.01-dev

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for compysition 1.1.01-dev
File Size Uploaded Provenance Actions
compysition-1.1.01-dev.tar.gz 42.4 kB Without provenance Details for compysition-1.1.01-dev.tar.gz

Release files / compysition-1.1.01-dev.tar.gz

Download URL compysition-1.1.01-dev.tar.gz
Size 42.4 kB
Tags Source
SHA-256 checksum
How to use checksums
4a7df0aa4c9403a446574768ca1aa0b26f1e65db7efd0ea006678eb7a15e6a6a
BLAKE2b-256 checksum
How to use checksums
afe5c428af3d15627ae0854eca5f6bcbbc49f28fec1285c0386dbbb0a5735bce
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No

Security for compysition 1.1.01-dev

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

1.2.0

1.1.23

1.1.06

This release

0.0.1

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page