A django based miniframework, inspired by Sinatra
Project description
Issues you can help with right now:
What is importd?
Slides of a talk I gave about importd: http://amitu.com/importd/
Django is awesome, but starting a new project in it is a pain. importd is inspired from ruby’s sinatra. Hello world django project:
from importd import d
d(DEBUG=True)
@d("/")
def idx(request):
return "index.html"
@d("/post/<int:post_id>/")
def post(request, post_id):
return "post.html", {"post_id": post_id}
if __name__ == "__main__":
d.main()
To run it:
$ python foo.py
This will start the debug server.
To run it in production:
$ gunicorn foo:d
Examples
Simple example : https://github.com/amitu/importd/tree/master/examples
importd-boilerplate : https://github.com/if1live/importd-boilerplate
importd + jinja2 + django-debug-toolbar + django REST framework
Settings Framework
Managing settings in django is done via a settings.py file. Then people put a local_settings.py to override. This does not scale too well, we end up having very big settings file with almost no structure, and there are many issues because of lack of synchronization of local_settings.py among developer’s machines.
importd has some methods to hopefully make this simpler and more standardized.
First of all there is no local_settings.py. Setting customization are of two kinds, picking different things for development and prod, eg you want to activate statsd for prod, but debug_toolbar for development. Both these should be checked in so there is no scope of people not getting some setting accidentally. Then there are setting customization for not storing some things in version control system, say passwords and access tokens and keys. These should be managed via environment variable.
And then there is also a concern of exposing settings to template. We have a template context processor, which can expost whole settings to templates, but that is uncomfortable to many. You may want to expose only a small subset of things you describe in settings, and you want to do this with minimal fuss.
importd.env
With that in mind importd has env(), which simply reads data from enironment. So in your app.py you can do:
from importd import d, env
d(
DEBUG=not env("IS_PROD", False),
db=env("DB_URL", "mysql://root:@localhost/dbname")
)
It is highly recommended you include envdir in your project. May be someday importd will auto detect envdir and set it up.
env is pretty smart, it takes default= and factory=. If default is passed, the string value of environment variable is converted to the type() of default. You can overwrite this behaviour by passing your own factory, or you can disable this behaviour altogether by passing factory=importd.NotSet.
env() also treats booleans by converting strings like “False/off/no” (case insensitive) to python’s False value (and non empty string to True as bool() does).
importd.debug
With .debug() you can set some setting to have different values based on DEBUG.
from importd import d, debug
d(
DEBUG=not env("IS_PROD", False),
STATSD_CLIENT=debug(
'django_statsd.clients.toolbar', prod='django_statsd.clients.normal'
),
)
This will set STATSD_CLIENT to appropriate value based on if we are in debug mode or not. This is as simple as putting an if condition, but it gets repeated so many times, its worth using this shortcut. Also this way things stay in same place, you do not look for up and down the settings file, and in local_settings.py to see if the variable has been overwritten.
importd.e
This lets you “expose” a setting for access in templates. You should not use "django.core.context_processors.settings" as a TEMPLATE_CONTEXT_PROCESSORS, instead use "importd.esettings" context preprocessor, and in templates you will have access to esettings variable.
To mark a variable as exposed you have to do this:
from importd import d, e
d(
DEBUG=True,
SOME_VAR=e("its value"),
)
This will make SOME_VAR available in settings as well as in esettings.
d(debug={}) parameter
Some settings are only needed in debug environment, or need to be overwritten, you can use the debug= keyword argument to set things up.
from importd import d
d(
DEBUG=False,
SOME_VAR="this is prod value",
debug=dict(
SOME_VAR="this is debug value"
)
)
You can also use importd.NotSet as a value in debug dict, and the setting will be removed altogether in the approprite environment (debug or prod).
debug:/prod: prefix for INSTALLED_APPS etc
It is a common pattern that some apps are only needed in debug environment, say devserver, or debug_toolbar. And since order of apps in INSTALLED_APPS, and middelware etc is important, we end up copying the whole INSTALLED_APPS, MIDDLEWARE_CLASSES etc for prod and dev, and this then tend to diverge since they are in different locations. Not good.
from importd import d, env
d(
DEBUG=env("IS_PROD", True),
INSTALLED_APPS=[
"django.contrib.contenttypes",
"django.contrib.auth",
"django.contrib.sessions",
"debug:devserver",
"debug:debug_toolbar",
"myapp"
]
)
Notice the debug: prefix in devserver and debug_toolbar. Depending on the value of DEBUG, these lines would be included or not. importd looks for strings in MIDDLEWARE_CLASSES, INSTALLED_APPS and TEMPLATE_CONTEXT_PROCESSORS.
Similarly if something starts with prod:, it is only included in production environment.
Backward Incompatibile Change
d.main() used to be not required, now it is.
Features
fully compatible with django
supports smarturls
most of regularly used django functions and classes available in d. namespace, eg d.HttpResponse, d.render_to_response, d.get_object_or_404 etc
automatically maps “templates” folder in foo.py directory to serve templates
automatically maps “static” folder in foo.py to serve static content
management commands still available: $ python foo.py shell
wsgi compliant
gunicorn support
works seamlessly with fhurl (http://packages.python.org/fhurl/)
Auto Add django-debug-toolbar (Needs to add it manually to INSTALLED_APPS)
Auto SECRET_KEY: If no SECRET_KEY on settings, try to read SECRET_KEY from ./secret.txt , if no ./secret.txt generate a random string then write it to ./secret.txt and finally return it as SECRET_KEY.
Auto Add coffin/django-jinja (jinja2 integration)
Support for livereload
Installation
$ pip install importd
Documentation
ChangeLog
Contributors
Amit Upadhyay (https://github.com/amitu)
Dmytro Vorona (https://github.com/alendit)
Jannis Leidel (https://twitter.com/jezdez)
Lukasz Balcerzak (https://github.com/lukaszb)
Juan Carlos (https://github.com/juancarlospaco)
Josep Cugat (https://github.com/jcugat)
Yu Byunghoo (https://github.com/if1live)
Contribution Guide
To view this file, or any restructuredtext file locally before comitting on git, install restview from pypi.
Pull Requests: If you fork this repository to send pull request, please create a branch for your work instead of working directly on master. This way your master will track my master, and in case the pull request is rejected, or delayed, your master stays clean. This also makes easy to send more than one pull requests from your fork.
LICENSE
BSD
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.