GitLocker: The Coding Marketplace

Description:

importd 0.4.3

Issues you can help with right now: |waffle|Build Status: |build-status| |build-health|.. |waffle| image:: https://badge.waffle.io/amitu/importd.png?label=ready&title=Ready :target: https://waffle.io/amitu/importd :alt: 'Stories in Ready'.. |build-status| image:: https://travis-ci.org/amitu/importd.png?branch=master :target: https://travis-ci.org/amitu/importd.. |build-health| image:: https://landscape.io/github/amitu/importd/master/landscape.svg :target: https://landscape.io/github/amitu/importd/master :alt: Code HealthWhat 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 isinspired from ruby's sinatra. Hello world django project:.. code-block:: python 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:.. code:: bash pythonfoo.pyThiswillstartthedebugserver.Torunitinproduction:..code::bash gunicorn foo:dExamples========* 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 frameworkSettings 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 uphaving very big settings file with almost no structure, and there are manyissues because of lack of synchronization of ``local_settings.py`` amongdeveloper'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 twokinds, picking different things for development and prod, eg you want toactivate statsd for prod, but debug_toolbar for development. Both these shouldbe checked in so there is no scope of people not getting some settingaccidentally. Then there are setting customization for not storing some thingsin version control system, say passwords and access tokens and keys. Theseshould be managed via environment variable.And then there is also a concern of exposing settings to template. We have atemplate context processor, which can expost whole settings to templates, butthat is uncomfortable to many. You may want to expose only a small subset ofthings 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 fromenironment. So in your app.py you can do:.. code:: python 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 somedayimportd 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" (caseinsensitive) 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``... code:: python 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 debugmode or not. This is as simple as putting an if condition, but it gets repeatedso many times, its worth using this shortcut. Also this way things stay in sameplace, you do not look for up and down the settings file, and inlocal_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"`` contextpreprocessor, and in templates you will have access to ``esettings`` variable.To mark a variable as exposed you have to do this:.. code:: python 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``.``importd.s``` parameter-------------------------This lets you re-use settings variables. In settings file we define variables and reuse them when needed. In importd you can reuse defined settings variables... code:: python from importd import d, s d( DEBUG=True, TEMPLATE_DEBUG=s("DEBUG") ) This will set ``TEMPLATE_DEBUG`` settings variable to ``DEBUG`` value. ``s`` will raise ``ImproperlyConfiguredError`` exception if you will try to use it inside of key value. .. code:: python from importd import d, s d( EMAIL="foo@example.com", ADMINS=(s("EMAIL"), "hello@example.com") )Above example will raise ``ImproperlyConfiguredError``. ``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... code:: python 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 willbe removed altogether in the approprite environment (debug or prod).d.openenv(path=None)---------------Above method will open envdir directory in current directory and will load all environment variable inside this directory. If path is realpath i.e. full paththen importd will try to look into specified path. If relative pathspecified into path then importd will look relative to current directory. It is recommended to call it just after importing d.debug:/prod: prefix for ``INSTALLED_APPS`` etc-----------------------------------------------It is a common pattern that some apps are only needed in debug environment, saydevserver, or debug_toolbar. And since order of apps in ``INSTALLED_APPS``, andmiddelware etc is important, we end up copying the whole ``INSTALLED_APPS``,``MIDDLEWARE_CLASSES`` etc for prod and dev, and this then tend to diverge sincethey are in different locations. Not good... code:: python 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``. Dependingon the value of ``DEBUG``, these lines would be included or not. importd looksfor strings in ``MIDDLEWARE_CLASSES``, ``INSTALLED_APPS`` and``TEMPLATE_CONTEXT_PROCESSORS``.Similarly if something starts with ``prod:``, it is only included in productionenvironment.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: pythonfoo.pyshell∗wsgicompliant∗gunicornsupport∗worksseamlesslywithfhurl(http://packages.python.org/fhurl/)∗AutoAdddjango−debug−toolbar(NeedstoadditmanuallytoINSTALLEDAPPS)∗AutoSECRETKEY:IfnoSECRETKEYonsettings,trytoreadSECRETKEYfrom./secret.txt,ifno./secret.txtgeneratearandomstringthenwriteitto./secret.txtandfinallyreturnitasSECRETKEY.∗AutoAddcoffin/django−jinja(jinja2integration)∗SupportforlivereloadInstallation============..code::bash pip install importdDocumentation=============http://importd.readthedocs.org/en/latest/ChangeLog=========https://github.com/amitu/importd/blob/master/ChangeLog.rstContributors============* 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)* Arpit Singh (https://github.com/arpitremarkable)* Hitul Mistry (https://github.com/hitul007)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, pleasecreate a branch for your work instead of working directly on master. This wayyour master will track my master, and in case the pull request is rejected, ordelayed, your master stays clean. This also makes easy to send more than onepull requests from your fork.LICENSE=======* BSDimportd ChangeLog=================0.4.3 - 12-Oct-2015-------------------* New tag s added. * It is recommended to call d.openenv before calling it in main. * Extra python path cannot be added into d as kwargs. 0.4.2 - 9-Oct-2015------------------* Fixed process_view of middleware not called. * Extra python path can be added into d as kwargs argument ENVDIR. 0.4.1 - 30-Sep-2015-------------------* Fixed AttributeError when calling d.dotslash. * don't auto configure ROOT_URLCONF if already configured0.4.0 - 27-Aug-2015-------------------Settings Framework Release* added `debug` keyword argument that takes dict and is added to base settings only if DEBUG is true* added importd.env, which checks a key in environment and if not present returns a default value (so that I do not have to write this utility everywhere)* added a importd.debug() that can be used for conditional settings* MIDDLEWARE_CLASSES, INSTALLED_APPS or TEMPLATE_CONTEXT_PROCESSORS is looked for settings that starts with "debug:", such values are dropped completely in prod, and in debug the "debug:" prefix is stripped. similarly we have "prod:".* created impoortd.e() which can be used to "expose" some of the settings to template. in order to use it in template, add a template context processor "importd.esettings", this will make available a variable named "esettings".0.3.3 - 24-Feb-2015-------------------* added livereload command/feature.0.3.2 - 27-Jan-2015-------------------* Added blueprint document.* calling django.setup() when available0.3.1 - 27-Oct-2014-------------------* released without blueprint thing. rereleasing.0.3.0 - 27-Oct-2014-------------------* Changed default setting STATIC_ROOT from ``static`` to ``staticfiles`` and set new default setting STATICFILES_DIRS to ``static``. This means that if you use the collectstatic management command, it will collect the files from the ``static`` folder and copy them to ``staticfiles``. If you use an external web server, you have to change the local path of the url http://server/static/ to serve files from the ``staticfiles`` folder.* Auto Add django-debug-toolbar: try to import it, if sucessful and is not on settings and the database exist(debug_toolbar needs a DB) and DEBUG=True, then configure debug_toolbar.* Auto Add 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 django.contrib.humanize.* Auto Add django.contrib.staticfiles.* Auto Import get_list_or_404, render, redirect from django.shortcuts.* Fixed Tests for new features.* Support django-debug-toolbar 1.2.1* Add importd-boilerplate hyperlink.* Auto Add coffin/django-jinja.* Added support for Django1.7 and Python3.4, removed support for python3.3.* Added autoimport keyword argument, to control if views etc should be auto imported.* Added a blueprint like framework inspired from flask0.2.9 - 10-Nov-2013-------------------* there was a bug in previous release, d.dotslash() always returned the same value if called before configuring django0.2.8 - 10-Nov-2013-------------------* integrated with speaklater(optional), if available, d.dotslash() can be used before django is configured, returns a lazy string, which becomes "available" after django has been configured. suitable for configuring template dirs or static files etc.0.2.7 - 4-Nov-2013------------------* db kwarg can now be a string or (string, dict), in later case dict would be merged into dict returned by dj_database_url.parse(), to support extra settings django allows eg OPTIONS, CONN_MAX_AGE[this one I particularly need in every projct, and dont want to miss out on using dj_database_url]0.2.6 - 4-Nov-2013------------------* support for django 1.6c10.2.5 - 4-Nov-2013------------------* now accepts db= kward when configuring, uses dj_database_url to parse db0.2.4 - 4-Nov-2013------------------* changes to serve admin static files0.2.3 - 16-Aug-2013-------------------* turns out importd depends on django :-)0.2.2 - 12-Aug-2013-------------------* support for django 1.3.7* testing django 1.5.2, 1.4.6 now.0.2.1 - 12-Aug-2013-------------------* packaging was broken, thank you @jezdez0.2.0 - 4-Aug-2013------------------There is a backward incompatible change in this release. importd has removedatexit magic, which means a call to d.main() must be included somewhere... code-block:: python from importd import d @d("/") def hello(request): return d.HttpResponse("hello world") if __name__ == "__main__": d.main() # NOTE THIS* BACKWARD INCOMPATIBLE: remove atexit magic, d.main() is the replacement* gunicorn cleanly exits now* tests, support django 1.4.3 and 1.5.1 for each of python 2.6, 2.7 and 3.3* less magic, no more sys.modules tweaking* runserver now reloads when any file changes* added auto generated MANIFEST.in (using check-manifest)* added support for mounting urls to custom locations0.1.4 - 22-Oct-2012-------------------* setup.py was buggy0.1.3 - 22-Oct-2012-------------------* setup.py was buggy0.1.2 - 13-Aug-2012-------------------* few bug fixes, APP_DIR was calculated incorrectly* automatically configure databases if DATABASES is not passed* auto import .views and .forms of each installed app to give all @d("pattern") decorators visibility* auto import .signals in each app to allow signals to register themselve, better than import them from models.py explicitly and fighting the circular imports issue0.1.1 - 8-Aug-2012------------------* refactored out smarturls into a separate project0.1.0 - 6-Aug-2012------------------Initial release.