%global _empty_manifest_terminate_build 0 Name: python-brewblox-service Version: 2.1.0 Release: 1 Summary: Scaffolding for Brewblox backend services License: GPL-3.0 URL: https://pypi.org/project/brewblox-service/ Source0: https://mirrors.nju.edu.cn/pypi/web/packages/09/a8/71659ee938d1e5da672507bea7a8789f0f8ae09a1cdda54174944f135feb/brewblox_service-2.1.0.tar.gz BuildArch: noarch Requires: python3-aiohttp Requires: python3-aiohttp-pydantic Requires: python3-aiomqtt %description # 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 . `brewblox-service` can technically be launched as a standalone application, but will not be very useful. ## [brewblox_service](./brewblox_service/__init__.py) 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: ```python from brewblox_service import brewblox_logger LOGGER = brewblox_logger(__name__) LOGGER.info('hello') ``` ## [service.py](./brewblox_service/service.py) Parses commandline arguments, creates an `aiohttp` app, and runs it. The shortest implementation is: ```python app = service.create_app(default_name='my_service') service.furnish(app) service.run(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: ```python # Separately creating the parser allows adding arguments to the default set parser = service.create_parser(default_name='my_service') parser.add_argument('--my-arg') # Now create the app app = service.create_app(parser=create_parser()) # Add features for this service device.setup(app) api.setup(app) # Furnish and run service.furnish(app) service.run(app) ``` ## [features.py](./brewblox_service/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)`) 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. ## [mqtt.py](./brewblox_service/mqtt.py) The replacement for the AMQP-based `events` module. The major advantages over AMQP is that the protocol is simpler, and supports websocket transport. This allows for it to be used outside a Brewblox network. Messages have a /-separated *topic* and a JSON-serialized body. 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 . For the Brewblox spec on how and where to publish data, see . Includes top-level convenience functions for `publish(topic, message)`, `listen(topic, callback)` and `subscribe(topic)`. %package -n python3-brewblox-service Summary: Scaffolding for Brewblox backend services Provides: python-brewblox-service BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-brewblox-service # 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 . `brewblox-service` can technically be launched as a standalone application, but will not be very useful. ## [brewblox_service](./brewblox_service/__init__.py) 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: ```python from brewblox_service import brewblox_logger LOGGER = brewblox_logger(__name__) LOGGER.info('hello') ``` ## [service.py](./brewblox_service/service.py) Parses commandline arguments, creates an `aiohttp` app, and runs it. The shortest implementation is: ```python app = service.create_app(default_name='my_service') service.furnish(app) service.run(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: ```python # Separately creating the parser allows adding arguments to the default set parser = service.create_parser(default_name='my_service') parser.add_argument('--my-arg') # Now create the app app = service.create_app(parser=create_parser()) # Add features for this service device.setup(app) api.setup(app) # Furnish and run service.furnish(app) service.run(app) ``` ## [features.py](./brewblox_service/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)`) 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. ## [mqtt.py](./brewblox_service/mqtt.py) The replacement for the AMQP-based `events` module. The major advantages over AMQP is that the protocol is simpler, and supports websocket transport. This allows for it to be used outside a Brewblox network. Messages have a /-separated *topic* and a JSON-serialized body. 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 . For the Brewblox spec on how and where to publish data, see . Includes top-level convenience functions for `publish(topic, message)`, `listen(topic, callback)` and `subscribe(topic)`. %package help Summary: Development documents and examples for brewblox-service Provides: python3-brewblox-service-doc %description help # 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 . `brewblox-service` can technically be launched as a standalone application, but will not be very useful. ## [brewblox_service](./brewblox_service/__init__.py) 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: ```python from brewblox_service import brewblox_logger LOGGER = brewblox_logger(__name__) LOGGER.info('hello') ``` ## [service.py](./brewblox_service/service.py) Parses commandline arguments, creates an `aiohttp` app, and runs it. The shortest implementation is: ```python app = service.create_app(default_name='my_service') service.furnish(app) service.run(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: ```python # Separately creating the parser allows adding arguments to the default set parser = service.create_parser(default_name='my_service') parser.add_argument('--my-arg') # Now create the app app = service.create_app(parser=create_parser()) # Add features for this service device.setup(app) api.setup(app) # Furnish and run service.furnish(app) service.run(app) ``` ## [features.py](./brewblox_service/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)`) 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. ## [mqtt.py](./brewblox_service/mqtt.py) The replacement for the AMQP-based `events` module. The major advantages over AMQP is that the protocol is simpler, and supports websocket transport. This allows for it to be used outside a Brewblox network. Messages have a /-separated *topic* and a JSON-serialized body. 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 . For the Brewblox spec on how and where to publish data, see . Includes top-level convenience functions for `publish(topic, message)`, `listen(topic, callback)` and `subscribe(topic)`. %prep %autosetup -n brewblox-service-2.1.0 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-brewblox-service -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Wed May 10 2023 Python_Bot - 2.1.0-1 - Package Spec generated