Conveniently separate your business logic from messaging stuff.
Happyly helps to abstract your business logic from messaging stuff, so that your code is maintainable and ensures separation of concerns. Actual actions your code perform are abstracted into universal Handlers which can be used with any serialization technology or messaging protocol without any change.
Happyly can be used with Flask, Celery, Django, Kafka or whatever technology which is utilized for messaging. Happyly also provides first-class support of Google Pub/Sub.
Why this name?
Happyly stands for HAndlers for Pub/sub as a PYthon LibrarY
The lib was originally created for usage with Google Pub/Sub, but it then turned out that the idea is much more universal and can simplify transition between messaging and serialization technologies.
pip install happyly
For additional components use
pip install happyly[google-cloud-pubsub]
pip install happyly[flask]
pip install happyly[redis]
- Create and activate a virtual environment (e.g.
python -m venv env; source env/bin/activate).
pip install flit.
flitto install the package with all development dependencies:
flit install. Repeat this whenever you want to account for new code changes or dependencies.
- Note that the repository uses pre-commit
to auto-check code for style and types.
Enable it for your cloned repo with
- In order to run tests, use either
pytest(tests against your current python version) or
tox(will try to test against all supported python versions).
- When you are ready to deploy the project,
major) and then
git push && git push --tags. Travis will detect it and automatically deploy the package to PyPI. It is also advised to create a new release on GitHub describing significant changes since the previous version. Important: at the time of writing, the package
bumpversionin PyPI is unmaintained and has several issues. Please use
bump2versioninstead. It will automatically be installed with
flit installas a developmment dependency, so no need to install it manually.
Note about versioning scheme
We use semantic versioning with added
each version (major, minor or patch) will start with
which is then advanced either to
rc2 etc using
or "released" using
bumpversion rel (which removed
rcN suffix completely).
bumpversin's point of view, there are two additional version parts:
rel (which can be either
rc or missing =
rc which denotes number of release candidate.
alpha is not used by
but can be used when specifying version manually:
bumpversion [major|minor|patch] --new-version 1.1.0alpha1.
If you use
bumpversion rel on such version, it will first transition from
and only then will it switch to
If you want to release new version skipping
rc stage (probably a
then you can use either of these methods:
bumpversion --new-version 1.0.1(substitute the desired new version) - not recommended;
- Recommended approach:
bumpversion --no-tag patch && bumpversion rel. This will create an intermediary commit for
rcbut won't create a tag for it and hence won't trigger deployment for intermediary