diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-aiorun.spec | 165 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 167 insertions, 0 deletions
@@ -0,0 +1 @@ +/aiorun-2022.11.1.tar.gz diff --git a/python-aiorun.spec b/python-aiorun.spec new file mode 100644 index 0000000..6a60957 --- /dev/null +++ b/python-aiorun.spec @@ -0,0 +1,165 @@ +%global _empty_manifest_terminate_build 0 +Name: python-aiorun +Version: 2022.11.1 +Release: 1 +Summary: Boilerplate for asyncio applications +License: None +URL: https://github.com/cjrh/aiorun +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/35/61/a5f5abfcfd98f1e50be42e46af3b9564c03f498c9fea6d262f704ae95b56/aiorun-2022.11.1.tar.gz +BuildArch: noarch + +Requires: python3-typing +Requires: python3-pytest +Requires: python3-pytest-cov + +%description +Here's the big idea (how you use it): + import asyncio + from aiorun import run + async def main(): + # Put your application code here + await asyncio.sleep(1.0) + if __name__ == '__main__': + run(main()) +This package provides a ``run()`` function as the starting point +of your ``asyncio``-based application. The ``run()`` function will +run forever. If you want to shut down when ``main()`` completes, just +call ``loop.stop()`` inside it: that will initiate shutdown. + Note that `aiorun.run(coro)` will run **forever**, unlike the standard + library's ``asyncio.run()`` helper. You can call `aiorun.run()` + without a coroutine parameter, and it will still run forever. + This is surprising to many people, because they sometimes expect that + unhandled exceptions should abort the program, with an exception and + a traceback. If you want this behaviour, please see the section on + *error handling* further down. + Note that `aiorun.run(coro)` will create a **new event loop instance** + every time it is invoked (same as `asyncio.run`). This might cause + confusing errors if your code interacts with the default event loop + instance provided by the stdlib `asyncio` library. For such situations + you can provide the actual loop you're using with + `aiorun.run(coro, loop=loop)`. There is more info about this further down. + However, generally speaking, configuring your own loop and providing + it in this way is a code smell. You will find it much easier to + reason about your code if you do all your task creation *inside* + an async context, such as within an `async def` function, because then + there will no ambiguity about which event loop is in play: it will + always be the one returned by `asyncio.get_running_loop()`. + +%package -n python3-aiorun +Summary: Boilerplate for asyncio applications +Provides: python-aiorun +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-aiorun +Here's the big idea (how you use it): + import asyncio + from aiorun import run + async def main(): + # Put your application code here + await asyncio.sleep(1.0) + if __name__ == '__main__': + run(main()) +This package provides a ``run()`` function as the starting point +of your ``asyncio``-based application. The ``run()`` function will +run forever. If you want to shut down when ``main()`` completes, just +call ``loop.stop()`` inside it: that will initiate shutdown. + Note that `aiorun.run(coro)` will run **forever**, unlike the standard + library's ``asyncio.run()`` helper. You can call `aiorun.run()` + without a coroutine parameter, and it will still run forever. + This is surprising to many people, because they sometimes expect that + unhandled exceptions should abort the program, with an exception and + a traceback. If you want this behaviour, please see the section on + *error handling* further down. + Note that `aiorun.run(coro)` will create a **new event loop instance** + every time it is invoked (same as `asyncio.run`). This might cause + confusing errors if your code interacts with the default event loop + instance provided by the stdlib `asyncio` library. For such situations + you can provide the actual loop you're using with + `aiorun.run(coro, loop=loop)`. There is more info about this further down. + However, generally speaking, configuring your own loop and providing + it in this way is a code smell. You will find it much easier to + reason about your code if you do all your task creation *inside* + an async context, such as within an `async def` function, because then + there will no ambiguity about which event loop is in play: it will + always be the one returned by `asyncio.get_running_loop()`. + +%package help +Summary: Development documents and examples for aiorun +Provides: python3-aiorun-doc +%description help +Here's the big idea (how you use it): + import asyncio + from aiorun import run + async def main(): + # Put your application code here + await asyncio.sleep(1.0) + if __name__ == '__main__': + run(main()) +This package provides a ``run()`` function as the starting point +of your ``asyncio``-based application. The ``run()`` function will +run forever. If you want to shut down when ``main()`` completes, just +call ``loop.stop()`` inside it: that will initiate shutdown. + Note that `aiorun.run(coro)` will run **forever**, unlike the standard + library's ``asyncio.run()`` helper. You can call `aiorun.run()` + without a coroutine parameter, and it will still run forever. + This is surprising to many people, because they sometimes expect that + unhandled exceptions should abort the program, with an exception and + a traceback. If you want this behaviour, please see the section on + *error handling* further down. + Note that `aiorun.run(coro)` will create a **new event loop instance** + every time it is invoked (same as `asyncio.run`). This might cause + confusing errors if your code interacts with the default event loop + instance provided by the stdlib `asyncio` library. For such situations + you can provide the actual loop you're using with + `aiorun.run(coro, loop=loop)`. There is more info about this further down. + However, generally speaking, configuring your own loop and providing + it in this way is a code smell. You will find it much easier to + reason about your code if you do all your task creation *inside* + an async context, such as within an `async def` function, because then + there will no ambiguity about which event loop is in play: it will + always be the one returned by `asyncio.get_running_loop()`. + +%prep +%autosetup -n aiorun-2022.11.1 + +%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-aiorun -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Tue Apr 11 2023 Python_Bot <Python_Bot@openeuler.org> - 2022.11.1-1 +- Package Spec generated @@ -0,0 +1 @@ +85c99f5e05792b5d9ab458ad0f9e17f8 aiorun-2022.11.1.tar.gz |