Kit
A configurable, lightweight framework that integrates Flask, SQLAlchemy, and Celery.
Configure all your applications and sessions from one file (cf. Quickstart for an example).
Run your project from the command line: Start the Werkzeug webserver, start Celery workers, start a shell in your project’s context (using IPython if available), and start the Flower monitor using the kit command line tool.
No more complicated import schemes: kit.Flask and kit.Celery always return the correct (and configured) application corresponding to the module.
Kit makes sure database connections are correctly handled (e.g. removed after each request and task) under the hood. You can configure this behavior via the kit.teardown_handler decorator.
Check out the examples/ folder for a few sample applications or read the full documentation on GitHub pages.
Kit is under development.
Installation
$ pip install kitQuickstart
Sample configuration file:
root: '..'
flasks:
- modules: ['my_project.app', 'my_project.app.views']
kwargs:
static_folder: 'st'
config:
debug: yes
testing: yes
- modules: ['my_project.api']
celeries:
- modules: ['my_project.tasks']
config:
broker_url: 'redis://'
sessions:
db:
url: 'mysql://...'
engine:
pool_recycle: 3600
options:
commit: yes
raise: no
modules: ['my_project.startup']The following configuration options are available:
root: project root, will be added to your python path (defaults to '.')
flasks: list of Flask application settings. Each item has the following keys available:
modules: list of modules where this application is used. Inside each of these modules, you can use kit.Flask(__name__) to recover this configured application. The application’s name will be automatically generated from this list of modules.
kwargs: dictionary of keyword arguments passed to the flask.Flask constructor.
config: dictionary of configuration options used to configure the application. Names are case insensitive so no need to uppercase them.
celeries: list of Celery application settings. Each item has the following keys available:
modules: list of modules where this application is used. Inside each of these modules, you can use kit.Celery(__name__) to recover this configured application. The application’s name will be automatically generated from this list of modules.
kwargs: dictionary of keyword arguments passed to the celery.Celery constructor.
config: dictionary of configuration options used to configure the application. Names are case insensitive so no need to uppercase them.
sessions: dictionary of sessions. The key is the session name (used as argument to kit.get_session). Each item has the following settings available:
url: the database url (defaults to sqlite://)
kwargs: dictionary of keyword arguments to pass to sqlalchemy.orm.sessionmaker.
engine: dictionary of keyword arguments to pass to the bound engine’s constructor.
options: there are currently two options available:
commit: whether or not to commit the session after each request or task (defaults to False).
raise: whether or not to reraise any errors found during commit (defaults to True).
modules: list of modules to import (and that don’t belong to an application).
You can then manage your project using the kit command line tool:
kit shell will start a shell in your project’s environment (all applications and sessions will have been created and set up beforehand).
kit server will run the Werkzeug server for one of your Flask applications (if several applications are found, you will be prompted to choose one).
kit worker will start a Celery worker (if more than one Celery application exists in your project, you will be prompted to choose one).
kit flower starts the Flower worker monitor.
kit -h displays usage and the list of options available for each of these commands.
Next steps
To instantiate an application outside of the command line tool (for example to run it on a different WSGI server), you can specify a path argument to the kit.Flask function. This will load the kit before returning the application. The path argument is available on all other functions as well (for example to allow model access from an IPython notebook).
1 maintainer
Metadata
1 maintainer
Release files for kit 0.2.15
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| kit-0.2.15.tar.gz | 24.1 kB | Without provenance | Details |
Release files / kit-0.2.15.tar.gz
| Download URL | kit-0.2.15.tar.gz |
|---|---|
| Size | 24.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4ac3c91ba502793eae8bf280674d169606d7c8606349d54b7bc9ea65089d9d81
|
|
BLAKE2b-256 checksum How to use checksums |
6d8320eb4b25622eb2eda2de15864b0daeec885070d0b305c1a0a7a6abc89d61
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for kit 0.2.15
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
