diff options
Diffstat (limited to 'python-django-banjo.spec')
| -rw-r--r-- | python-django-banjo.spec | 573 |
1 files changed, 573 insertions, 0 deletions
diff --git a/python-django-banjo.spec b/python-django-banjo.spec new file mode 100644 index 0000000..f53439d --- /dev/null +++ b/python-django-banjo.spec @@ -0,0 +1,573 @@ +%global _empty_manifest_terminate_build 0 +Name: python-django-banjo +Version: 0.3.0 +Release: 1 +Summary: A simplified abstraction over django for beginners. +License: MIT License +URL: https://github.com/cproctor/django-banjo +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/35/21/1e38ccec884d1d4a5bf35ca2dd0d5b46a0b64fd83299234cfe696cd13319/django-banjo-0.3.0.tar.gz +BuildArch: noarch + +Requires: python3-django +Requires: python3-django-extensions +Requires: python3-environ + +%description +# Banjo + +Banjo is an abstraction over django which provides a simplified subset of django's +functionality, meant for beginners. All the django documentation can be used for +reference, and many django patterns are replicated here. + +## Needs + +The purpose of Banjo is to introduce databases as a persistence layer behind an +API server, while abstracting away details for which students are not yet ready +and creating as few misconceptions as possible. +Banjo should be thought of as scaffolding; when they are ready, students should +be able to seamlessly transition to django. + +Specific concepts which we target for simplification include: + +- Simplify DB schema: A severely-limited subset of field types is provided. + Field names correspond to familiar Python types. All fields have default values. + Migrations are handled automatically. Within these constraints, django's full + ORM is available. +- Simplify filesystem layout: Only two files are required: `models.py` and + `views.py`. +- Simplify management commands: There is a single command, `banjo`, which + effectively runs django's `makemigrations`, `migrate`, and `runserver` in sequence. + `banjo --shell` enters the REPL with all user-defined models loaded. +- Simplify request/response lifecycle: View functions receive a dict of params and + must return a dict. View-URL binding is handled by decorators, as in flask, and all + URLs are static (there are no placeholders and no params are passed to the + view). Http errors are provided as exceptions, which simplifies control flow. + Models have `from_dict` (class method) and `to_dict` (instance method) helpers. + +Banjo was designed for use by teachers familiar with django; this is intentionally a +leaky abstraction which provides a structured introduction into the power and +the complexity of the underlying system. + +## Creating an app + +Banjo can be installed with `pip install django-banjo`. + +To write a Banjo app, create a folder called `app`, define models in `models.py` and +define views in `views.py`. Here's a simple example. + +### Models + +First, we define our models. Banjo provides five field types: + +- `BooleanField` (`True`, `False`) +- `IntegerField` (`1`, `-102`) +- `FloatField` (`0.045`, `11.5`) +- `StringField` (`"alligator"`, `"hazelnut"`) +- `ForeignKey` (An instance of another model) + +Create a Model for each object your app will interact with. + + # app/models.py + from banjo.models import Model, StringField + + class Animal(Model): + name = StringField() + sound = StringField() + +### Views + +Next we define our views. Each view is a function which receives a dict (called +`params` in the example below) and which must return a dict. Use the +`banjo.urls.route_get` and `banjo.urls.route_post` decorators to route URLs to +your view functions. + + # app/views.py + from banjo.urls import route_get, route_post + from app.models import Animal + + @route_post('newanimal', args={'name': str, 'sound': str}) + def add_animal(params): + animal = Animal.from_dict(params) + animal.save() + return animal.to_dict() + + @route_get('listen') + def list_animal_sounds(params): + sounds = [] + for animal in Animal.objects.all(): + sounds.append('{} says {}'.format(animal.name, animal.sound)) + return {'sounds': sounds} + +Some views, such as "newanimal," require arguments. When a view requires arguments, +pass an `args` dict to the decorator to specify the expected names and types of arguments. +Argument types must be `str`, `bool`, `int`, or `float`. + +### HTTP errors + +If something goes wrong and it's the client's fault, you can raise an error. +For example, you might add another view to `app/views.py`: + + from banjo.http import Forbidden + + @route_get('secrets') + def do_not_show_the_secrets(params): + raise Forbidden("Nice try.") + +Again, from the command line: + + $ http GET localhost:5000/secrets + HTTP/1.1 403 Forbidden + + { + "error": "Nice try." + } + + +The following errors are available in `banjo.http`: + +- `BadRequest` (400) +- `Forbidden` (403) +- `NotFound` (404) +- `NotAllowed` (405) +- `ImATeapot` (418) + +## Running the app + +Now you can run `banjo` from the directory containing the `app` folder and the server +will start. Use the `--port` command to serve from a custom port; the default is +5000. + +Banjo provides a visual API browser at `/api`. + + + +Here is an example of interacting with this app using the `httpie` command-line +utility: + + $ http localhost:5000/newanimal name=elehpant sound=pffffftttttt + + { + "id": 1, + "name": "elephant", + "sound": "pffffftttttt" + } + + $ http localhost:5000/newanimal name=squirrel sound=chcheee + + { + "id": 2, + "name": "squirrel", + "sound": "chcheee" + } + + $ http localhost:5000/listen + + { + "sounds": [ + "elephant says pffffftttttt", + "squirrel says chcheee" + ] + } + + +## Shell + +You can also interact with your app's models from a Python shell. Just pass the +`--shell` argument to banjo: + + $ banjo --shell + > Animal.objects.count() + 2 + + + +%package -n python3-django-banjo +Summary: A simplified abstraction over django for beginners. +Provides: python-django-banjo +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-django-banjo +# Banjo + +Banjo is an abstraction over django which provides a simplified subset of django's +functionality, meant for beginners. All the django documentation can be used for +reference, and many django patterns are replicated here. + +## Needs + +The purpose of Banjo is to introduce databases as a persistence layer behind an +API server, while abstracting away details for which students are not yet ready +and creating as few misconceptions as possible. +Banjo should be thought of as scaffolding; when they are ready, students should +be able to seamlessly transition to django. + +Specific concepts which we target for simplification include: + +- Simplify DB schema: A severely-limited subset of field types is provided. + Field names correspond to familiar Python types. All fields have default values. + Migrations are handled automatically. Within these constraints, django's full + ORM is available. +- Simplify filesystem layout: Only two files are required: `models.py` and + `views.py`. +- Simplify management commands: There is a single command, `banjo`, which + effectively runs django's `makemigrations`, `migrate`, and `runserver` in sequence. + `banjo --shell` enters the REPL with all user-defined models loaded. +- Simplify request/response lifecycle: View functions receive a dict of params and + must return a dict. View-URL binding is handled by decorators, as in flask, and all + URLs are static (there are no placeholders and no params are passed to the + view). Http errors are provided as exceptions, which simplifies control flow. + Models have `from_dict` (class method) and `to_dict` (instance method) helpers. + +Banjo was designed for use by teachers familiar with django; this is intentionally a +leaky abstraction which provides a structured introduction into the power and +the complexity of the underlying system. + +## Creating an app + +Banjo can be installed with `pip install django-banjo`. + +To write a Banjo app, create a folder called `app`, define models in `models.py` and +define views in `views.py`. Here's a simple example. + +### Models + +First, we define our models. Banjo provides five field types: + +- `BooleanField` (`True`, `False`) +- `IntegerField` (`1`, `-102`) +- `FloatField` (`0.045`, `11.5`) +- `StringField` (`"alligator"`, `"hazelnut"`) +- `ForeignKey` (An instance of another model) + +Create a Model for each object your app will interact with. + + # app/models.py + from banjo.models import Model, StringField + + class Animal(Model): + name = StringField() + sound = StringField() + +### Views + +Next we define our views. Each view is a function which receives a dict (called +`params` in the example below) and which must return a dict. Use the +`banjo.urls.route_get` and `banjo.urls.route_post` decorators to route URLs to +your view functions. + + # app/views.py + from banjo.urls import route_get, route_post + from app.models import Animal + + @route_post('newanimal', args={'name': str, 'sound': str}) + def add_animal(params): + animal = Animal.from_dict(params) + animal.save() + return animal.to_dict() + + @route_get('listen') + def list_animal_sounds(params): + sounds = [] + for animal in Animal.objects.all(): + sounds.append('{} says {}'.format(animal.name, animal.sound)) + return {'sounds': sounds} + +Some views, such as "newanimal," require arguments. When a view requires arguments, +pass an `args` dict to the decorator to specify the expected names and types of arguments. +Argument types must be `str`, `bool`, `int`, or `float`. + +### HTTP errors + +If something goes wrong and it's the client's fault, you can raise an error. +For example, you might add another view to `app/views.py`: + + from banjo.http import Forbidden + + @route_get('secrets') + def do_not_show_the_secrets(params): + raise Forbidden("Nice try.") + +Again, from the command line: + + $ http GET localhost:5000/secrets + HTTP/1.1 403 Forbidden + + { + "error": "Nice try." + } + + +The following errors are available in `banjo.http`: + +- `BadRequest` (400) +- `Forbidden` (403) +- `NotFound` (404) +- `NotAllowed` (405) +- `ImATeapot` (418) + +## Running the app + +Now you can run `banjo` from the directory containing the `app` folder and the server +will start. Use the `--port` command to serve from a custom port; the default is +5000. + +Banjo provides a visual API browser at `/api`. + + + +Here is an example of interacting with this app using the `httpie` command-line +utility: + + $ http localhost:5000/newanimal name=elehpant sound=pffffftttttt + + { + "id": 1, + "name": "elephant", + "sound": "pffffftttttt" + } + + $ http localhost:5000/newanimal name=squirrel sound=chcheee + + { + "id": 2, + "name": "squirrel", + "sound": "chcheee" + } + + $ http localhost:5000/listen + + { + "sounds": [ + "elephant says pffffftttttt", + "squirrel says chcheee" + ] + } + + +## Shell + +You can also interact with your app's models from a Python shell. Just pass the +`--shell` argument to banjo: + + $ banjo --shell + > Animal.objects.count() + 2 + + + +%package help +Summary: Development documents and examples for django-banjo +Provides: python3-django-banjo-doc +%description help +# Banjo + +Banjo is an abstraction over django which provides a simplified subset of django's +functionality, meant for beginners. All the django documentation can be used for +reference, and many django patterns are replicated here. + +## Needs + +The purpose of Banjo is to introduce databases as a persistence layer behind an +API server, while abstracting away details for which students are not yet ready +and creating as few misconceptions as possible. +Banjo should be thought of as scaffolding; when they are ready, students should +be able to seamlessly transition to django. + +Specific concepts which we target for simplification include: + +- Simplify DB schema: A severely-limited subset of field types is provided. + Field names correspond to familiar Python types. All fields have default values. + Migrations are handled automatically. Within these constraints, django's full + ORM is available. +- Simplify filesystem layout: Only two files are required: `models.py` and + `views.py`. +- Simplify management commands: There is a single command, `banjo`, which + effectively runs django's `makemigrations`, `migrate`, and `runserver` in sequence. + `banjo --shell` enters the REPL with all user-defined models loaded. +- Simplify request/response lifecycle: View functions receive a dict of params and + must return a dict. View-URL binding is handled by decorators, as in flask, and all + URLs are static (there are no placeholders and no params are passed to the + view). Http errors are provided as exceptions, which simplifies control flow. + Models have `from_dict` (class method) and `to_dict` (instance method) helpers. + +Banjo was designed for use by teachers familiar with django; this is intentionally a +leaky abstraction which provides a structured introduction into the power and +the complexity of the underlying system. + +## Creating an app + +Banjo can be installed with `pip install django-banjo`. + +To write a Banjo app, create a folder called `app`, define models in `models.py` and +define views in `views.py`. Here's a simple example. + +### Models + +First, we define our models. Banjo provides five field types: + +- `BooleanField` (`True`, `False`) +- `IntegerField` (`1`, `-102`) +- `FloatField` (`0.045`, `11.5`) +- `StringField` (`"alligator"`, `"hazelnut"`) +- `ForeignKey` (An instance of another model) + +Create a Model for each object your app will interact with. + + # app/models.py + from banjo.models import Model, StringField + + class Animal(Model): + name = StringField() + sound = StringField() + +### Views + +Next we define our views. Each view is a function which receives a dict (called +`params` in the example below) and which must return a dict. Use the +`banjo.urls.route_get` and `banjo.urls.route_post` decorators to route URLs to +your view functions. + + # app/views.py + from banjo.urls import route_get, route_post + from app.models import Animal + + @route_post('newanimal', args={'name': str, 'sound': str}) + def add_animal(params): + animal = Animal.from_dict(params) + animal.save() + return animal.to_dict() + + @route_get('listen') + def list_animal_sounds(params): + sounds = [] + for animal in Animal.objects.all(): + sounds.append('{} says {}'.format(animal.name, animal.sound)) + return {'sounds': sounds} + +Some views, such as "newanimal," require arguments. When a view requires arguments, +pass an `args` dict to the decorator to specify the expected names and types of arguments. +Argument types must be `str`, `bool`, `int`, or `float`. + +### HTTP errors + +If something goes wrong and it's the client's fault, you can raise an error. +For example, you might add another view to `app/views.py`: + + from banjo.http import Forbidden + + @route_get('secrets') + def do_not_show_the_secrets(params): + raise Forbidden("Nice try.") + +Again, from the command line: + + $ http GET localhost:5000/secrets + HTTP/1.1 403 Forbidden + + { + "error": "Nice try." + } + + +The following errors are available in `banjo.http`: + +- `BadRequest` (400) +- `Forbidden` (403) +- `NotFound` (404) +- `NotAllowed` (405) +- `ImATeapot` (418) + +## Running the app + +Now you can run `banjo` from the directory containing the `app` folder and the server +will start. Use the `--port` command to serve from a custom port; the default is +5000. + +Banjo provides a visual API browser at `/api`. + + + +Here is an example of interacting with this app using the `httpie` command-line +utility: + + $ http localhost:5000/newanimal name=elehpant sound=pffffftttttt + + { + "id": 1, + "name": "elephant", + "sound": "pffffftttttt" + } + + $ http localhost:5000/newanimal name=squirrel sound=chcheee + + { + "id": 2, + "name": "squirrel", + "sound": "chcheee" + } + + $ http localhost:5000/listen + + { + "sounds": [ + "elephant says pffffftttttt", + "squirrel says chcheee" + ] + } + + +## Shell + +You can also interact with your app's models from a Python shell. Just pass the +`--shell` argument to banjo: + + $ banjo --shell + > Animal.objects.count() + 2 + + + +%prep +%autosetup -n django-banjo-0.3.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-django-banjo -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 0.3.0-1 +- Package Spec generated |