Scaffolding for Brewblox service applications
In order to reduce code duplication between services, generic functionality is implemented here.
For an example on how to implement your own service based on brewblox-service, see https://github.com/brewblox/brewblox-boilerplate.
brewblox_service
Small generic tools are defined here.
brewblox_logger can be used for creating module-specific loggers. It is not required, but will play a bit nicer with default formatting of the log.
Example:
from brewblox_service import brewblox_logger
LOGGER = brewblox_logger(__name__)
LOGGER.info('hello')
service.py
Parses commandline arguments, creates an aiohttp application object, and runs it.
The shortest implementation is:
parser = service.create_parser('my_service')
config = service.create_config(parser)
app = service.create_app(config)
service.run_app(app)
This will get you a working web application, but it will not have any endpoints.
Applications can configure their own features, and add new commandline arguments.
Example:
class ExtendedConfig(models.BaseServiceConfig):
my_arg: str
# Separately creating the parser allows adding arguments to the default set
parser = service.create_parser('my_service')
parser.add_argument('--my-arg')
# Get a config object from the extended args
config = service.create_config(parser, model=ExtendedConfig)
# Now create the app
app = service.create_app(config)
async def setup():
# Add features for this service
# You can call async functions here
device.setup(app)
api.setup(app)
# Run the app. It will await the setup() coroutine
service.run_app(app, setup())
features.py
Many service features are application-scoped. Their lifecycle should span multiple requests, either because they are not request-driven, or because they manage asynchronous I/O operations (such as listening to AMQP messages).
The ServiceFeature class offers an abstract base class for this behavior. Implementing classes should define startup(app) and shutdown(app) functions, and those will be automatically called when the application starts up and shuts down.
Both startup() and shutdown() are called in an async context, making them the async counterparts of __init__() and __del__() functions.
Features must be constructed after the app is created, but before it starts running. (service.create_app() and service.run_app(app)).
It is recommended but not required to add features in an async setup function.
The add() and get() functions make it easy to centrally declare a feature, and then use it in any function that has a reference to the aiohttp app.
repeater.py
A very common use case for features is to have the equivalent of a while True loop.
The RepeaterFeature class handles the boilerplate involved in setting this up in an async context.
mqtt.py
Basic MQTT messaging: publish and listen to events.
To publish data, all you need is the publish(topic, message) function.
To listen to incoming messages, you can combine subscribe(topic) with one or more calls to listen(topic, callback).
The subscribe/listen functions allow for + and # wildcards to be used.
For a detailed explanation of how to use MQTT topics, see http://www.steves-internet-guide.com/understanding-mqtt-topics/.
For the Brewblox spec on how and where to publish data, see https://brewblox.com/dev/reference/events.html.
Includes top-level convenience functions for publish(topic, message), listen(topic, callback) and subscribe(topic).
1 maintainer
Metadata
1 maintainer
Release files for brewblox-service 3.3.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| brewblox_service-3.3.2.tar.gz | 28.8 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| brewblox_service-3.3.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 60.9 kB
Release files / brewblox_service-3.3.2.tar.gz
| Download URL | brewblox_service-3.3.2.tar.gz |
|---|---|
| Size | 28.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0bf13ecf42729978cb9e4b2b3f5b4c5b2623bdc1aab16581fa6ca299ca6b4eac
|
|
BLAKE2b-256 checksum How to use checksums |
fcb3a2855a743646eb5704801d6005aade03f97b18f7ead631a79da2df6bb639
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/4.0.2 CPython/3.11.5
|
Release files / brewblox_service-3.3.2-py3-none-any.whl
| Download URL | brewblox_service-3.3.2-py3-none-any.whl |
|---|---|
| Size | 32.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
2b0bb621956a61e7846fa30d8005df8428416a0e3fe1ae2729f081d36bf7d8e3
|
|
BLAKE2b-256 checksum How to use checksums |
79e6af39a6dc5f0083c4a2a4f3f76fc03988960a09865eb9c513dc961881a909
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/4.0.2 CPython/3.11.5
|
Security for brewblox-service 3.3.2
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.
