%global _empty_manifest_terminate_build 0
Name:		python-aioflask
Version:	0.4.0
Release:	1
Summary:	Flask running on asyncio.
License:	MIT License
URL:		https://github.com/miguelgrinberg/aioflask
Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/9d/07/ac0afe199fde1764927ce68f254e9fe3c174c4bb689f74b8a40974c5b4cc/aioflask-0.4.0.tar.gz
BuildArch:	noarch

Requires:	python3-greenletio
Requires:	python3-flask
Requires:	python3-uvicorn

%description
# aioflask

![Build status](https://github.com/miguelgrinberg/aioflask/workflows/build/badge.svg) [![codecov](https://codecov.io/gh/miguelgrinberg/aioflask/branch/main/graph/badge.svg?token=CDMKF3L0ID)](https://codecov.io/gh/miguelgrinberg/aioflask)

Flask 2.x running on asyncio!

Is there a purpose for this, now that Flask 2.0 is out with support for async
views? Yes! Flask's own support for async handlers is very limited, as the
application still runs inside a WSGI web server, which severely limits
scalability. With aioflask you get a true ASGI application, running in a 100%
async environment.

WARNING: This is an experiment at this point. Not at all production ready!

## Quick start

To use async view functions and other handlers, use the `aioflask` package
instead of `flask`.

The `aioflask.Flask` class is a subclass of `flask.Flask` that changes a few
minor things to help the application run properly under the asyncio loop. In
particular, it overrides the following aspects of the application instance:

- The `route`, `before_request`, `before_first_request`, `after_request`, 
  `teardown_request`, `teardown_appcontext`, `errorhandler` and `cli.command`
  decorators accept coroutines as well as regular functions. The handlers all
  run inside an asyncio loop, so when using regular functions, care must be
  taken to not block.
- The WSGI callable entry point is replaced with an ASGI equivalent.
- The `run()` method uses uvicorn as web server.

There are also changes outside of the `Flask` class:

- The `flask aiorun` command starts an ASGI application using the uvicorn web
  server.
- The `render_template()` and `render_template_string()` functions are
  asynchronous and must be awaited.
- The context managers for the Flask application and request contexts are
  async.
- The test client and test CLI runner use coroutines.

## Example

```python
import asyncio
from aioflask import Flask, render_template

app = Flask(__name__)

@app.route('/')
async def index():
    await asyncio.sleep(1)
    return await render_template('index.html')
```




%package -n python3-aioflask
Summary:	Flask running on asyncio.
Provides:	python-aioflask
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-aioflask
# aioflask

![Build status](https://github.com/miguelgrinberg/aioflask/workflows/build/badge.svg) [![codecov](https://codecov.io/gh/miguelgrinberg/aioflask/branch/main/graph/badge.svg?token=CDMKF3L0ID)](https://codecov.io/gh/miguelgrinberg/aioflask)

Flask 2.x running on asyncio!

Is there a purpose for this, now that Flask 2.0 is out with support for async
views? Yes! Flask's own support for async handlers is very limited, as the
application still runs inside a WSGI web server, which severely limits
scalability. With aioflask you get a true ASGI application, running in a 100%
async environment.

WARNING: This is an experiment at this point. Not at all production ready!

## Quick start

To use async view functions and other handlers, use the `aioflask` package
instead of `flask`.

The `aioflask.Flask` class is a subclass of `flask.Flask` that changes a few
minor things to help the application run properly under the asyncio loop. In
particular, it overrides the following aspects of the application instance:

- The `route`, `before_request`, `before_first_request`, `after_request`, 
  `teardown_request`, `teardown_appcontext`, `errorhandler` and `cli.command`
  decorators accept coroutines as well as regular functions. The handlers all
  run inside an asyncio loop, so when using regular functions, care must be
  taken to not block.
- The WSGI callable entry point is replaced with an ASGI equivalent.
- The `run()` method uses uvicorn as web server.

There are also changes outside of the `Flask` class:

- The `flask aiorun` command starts an ASGI application using the uvicorn web
  server.
- The `render_template()` and `render_template_string()` functions are
  asynchronous and must be awaited.
- The context managers for the Flask application and request contexts are
  async.
- The test client and test CLI runner use coroutines.

## Example

```python
import asyncio
from aioflask import Flask, render_template

app = Flask(__name__)

@app.route('/')
async def index():
    await asyncio.sleep(1)
    return await render_template('index.html')
```




%package help
Summary:	Development documents and examples for aioflask
Provides:	python3-aioflask-doc
%description help
# aioflask

![Build status](https://github.com/miguelgrinberg/aioflask/workflows/build/badge.svg) [![codecov](https://codecov.io/gh/miguelgrinberg/aioflask/branch/main/graph/badge.svg?token=CDMKF3L0ID)](https://codecov.io/gh/miguelgrinberg/aioflask)

Flask 2.x running on asyncio!

Is there a purpose for this, now that Flask 2.0 is out with support for async
views? Yes! Flask's own support for async handlers is very limited, as the
application still runs inside a WSGI web server, which severely limits
scalability. With aioflask you get a true ASGI application, running in a 100%
async environment.

WARNING: This is an experiment at this point. Not at all production ready!

## Quick start

To use async view functions and other handlers, use the `aioflask` package
instead of `flask`.

The `aioflask.Flask` class is a subclass of `flask.Flask` that changes a few
minor things to help the application run properly under the asyncio loop. In
particular, it overrides the following aspects of the application instance:

- The `route`, `before_request`, `before_first_request`, `after_request`, 
  `teardown_request`, `teardown_appcontext`, `errorhandler` and `cli.command`
  decorators accept coroutines as well as regular functions. The handlers all
  run inside an asyncio loop, so when using regular functions, care must be
  taken to not block.
- The WSGI callable entry point is replaced with an ASGI equivalent.
- The `run()` method uses uvicorn as web server.

There are also changes outside of the `Flask` class:

- The `flask aiorun` command starts an ASGI application using the uvicorn web
  server.
- The `render_template()` and `render_template_string()` functions are
  asynchronous and must be awaited.
- The context managers for the Flask application and request contexts are
  async.
- The test client and test CLI runner use coroutines.

## Example

```python
import asyncio
from aioflask import Flask, render_template

app = Flask(__name__)

@app.route('/')
async def index():
    await asyncio.sleep(1)
    return await render_template('index.html')
```




%prep
%autosetup -n aioflask-0.4.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-aioflask -f filelist.lst
%dir %{python3_sitelib}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Tue May 30 2023 Python_Bot <Python_Bot@openeuler.org> - 0.4.0-1
- Package Spec generated