summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCoprDistGit <infra@openeuler.org>2023-05-10 04:46:05 +0000
committerCoprDistGit <infra@openeuler.org>2023-05-10 04:46:05 +0000
commit4e118682c2d9675bbb1c71abaac0a4a014bf23ce (patch)
tree00d219bc12a77d3fc4fffc7b522349a8a2f06fc2
parente841f5509b0eda02ffdf6147823b5abe7045bf4a (diff)
automatic import of python-brewblox-serviceopeneuler20.03
-rw-r--r--.gitignore1
-rw-r--r--python-brewblox-service.spec345
-rw-r--r--sources1
3 files changed, 347 insertions, 0 deletions
diff --git a/.gitignore b/.gitignore
index e69de29..a268f88 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/brewblox_service-2.1.0.tar.gz
diff --git a/python-brewblox-service.spec b/python-brewblox-service.spec
new file mode 100644
index 0000000..053a652
--- /dev/null
+++ b/python-brewblox-service.spec
@@ -0,0 +1,345 @@
+%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 <https://github.com/brewblox/brewblox-boilerplate>.
+
+`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 <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)`.
+
+
+
+%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 <https://github.com/brewblox/brewblox-boilerplate>.
+
+`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 <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)`.
+
+
+
+%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 <https://github.com/brewblox/brewblox-boilerplate>.
+
+`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 <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)`.
+
+
+
+%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 <Python_Bot@openeuler.org> - 2.1.0-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..ae61c04
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+bb6b67f1ddf2a7850d9b6907b53a2558 brewblox_service-2.1.0.tar.gz