{
    "info": {
        "author": "Simone Deponti",
        "author_email": "simone.deponti@abstract.it",
        "bugtrack_url": null,
        "classifiers": [
            "Framework :: Buildout",
            "Framework :: Django",
            "Intended Audience :: Developers",
            "License :: OSI Approved :: BSD License",
            "Topic :: Software Development :: Build Tools"
        ],
        "description": ".. contents::\n\nThis recipe allows you to setup a Django project through `zc.buildout`_.\n\nUsage\n*****\n\nIn order to use this recipe, create a buildout as follows::\n\n    [buildout]\n    parts =\n        myproject\n\n    [myproject]\n    recipe = djc.recipe2\n\nAnd then create a python module in ``sites/<part_name>_site_config``\ncontaining the ``settings.py`` file.\n\nThe buildout will take care of creating a manage script at ``bin/django``\nand a *WSGI* app to serve the project in production\nat ``parts/myproject/myproject_part_site/wsgi.py``.\n\nIn our example, this will result in the following file structure::\n\n    <buildout_root>\n    |\n    |- bin\n    |  |\n    |  |- ...\n    |  |\n    |  |- django # the manage.py script\n    |\n    |- ...\n    |\n    |- parts\n    |  |\n    |  |- myproject\n    |     |\n    |     |- myproject_part_site # put this on PYTHONPATH when serving via WSGI\n    |        |\n    |        |- __init__.py\n    |        |\n    |        |- ...\n    |        |\n    |        |- wsgi.py # WSGI app and paster app factory\n    |\n    |- ...\n    |\n    |- sites\n    |  |\n    |  |- myproject_site_config\n    |     |\n    |     |- __init__.py # void\n    |     |\n    |     |- settings.py # your settings here\n    |\n    |- ...\n\nFor all the options and detailed documentation, see below.\n\nRunning tests\n*************\n\nThe ``recipe.rst`` file located within the package also acts as main doctest.\n\nTo run the tests, check out the source,\nand then bootstrap and run the buildout::\n\n    $ python bootstrap.py\n    $ bin/buildout\n\nIf it's a fresh checkout you should also run::\n\n    $ ./makecache.sh\n\nThis command should be run just once after checking out:\nit will download certain packages needed for the tests\nso that they can run offline.\n\nIt should also be re-run if ``makecache.sh`` has changed.\n\nThen you can run the tests using::\n\n    $ bin/test\n\nLinks\n*****\n\n.. image:: https://secure.travis-ci.org/abstract-open-solutions/djc.recipe2.png\n\n- Code repository: http://github.com/abstract-open-solutions/djc.recipe2\n- Discussions at https://groups.google.com/group/djcrecipe\n- Comments and questions at info@abstract.it\n\n.. _`zc.buildout`: http://www.buildout.org/\n\n\nDetailed documentation\n**********************\n\nBasic usage\n===========\n\nThe basic thing you have to do in order to have a Django_ site\nis to provide it some configuration.\n\nIn Django_, configuration is achieved by creating a set of global variables\nin a `settings module`_ and letting Django_ know which is the\nsettings module to use.\n\nThis recipe, in its basic functioning, adopts a *convention over configuration*\napproach to the matter.\n\n.. note::\n   It is also possible to use other approaches,\n   as explained in `External settings`_.\n\nTherefore, all the configurations for all the Django_ parts in your buildout **must** be places within a ``sites`` directory located in your buildout root.\n\nWithin this directory, a *python module* (create an empty ``__init__.py``!)\nnamed ``<part_name>_site_config`` must be created, and within it,\na ``settings.py`` file containing your settings must be placed.\n\nFor example, if our Django_ part is named ``myproject``\n(we are referring to the buildout part name here),\nwe would do the following::\n\n    >>> mkdir('sites')\n    >>> mkdir('sites', 'myproject_site_config')\n    >>> write('sites', 'myproject_site_config', '__init__.py',\n    ...       '#\\n')\n    >>> write('sites', 'myproject_site_config', 'settings.py', '''\n    ... SPAM = 'eggs'\n    ... ''')\n\nOkay, that settings file is not exactly a good one,\nbut it will suffice for now as an example.\n\nLet's now create our buildout and run it::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n\nAs you can see, the part for now contains only the recipe, as it will work\n*out of the box* without further meddling if we adhere to its conventions.\n\nLet's see what the buildout did. To start with, it created a ``django`` binary\nwithin ``bin`` that is the equivalent of Django's ``manage.py``\n(which means you can invoke it exactly like you would with ``manage.py``)::\n\n    >>> ls('bin')\n    -  buildout\n    -  django\n\n.. note::\n   Ofcourse, since the binary name is always ``django``,\n   this will cause problems if you have more than one Django_ part\n   in your buildout:\n   this is solved by the `manage-py-file`_ option\n   explained in the `Options reference`_.\n\nThe next thing the buildout did is to create yet another python module\n(in ``parts/<part_name>``)::\n\n    >>> ls('parts', 'myproject')\n    d  myproject_part_site\n    >>> ls('parts', 'myproject', 'myproject_part_site')\n    -  __init__.py\n    -  settings.py\n    -  wsgi.py\n\n**Another** python module?\n\nYes, because unlike the first one, this is under buildout's strict control,\nand generated each time you run ``bin/buildout``\n(therefore, it is a *very bad idea* to edit those files,\nbecause your changes won't be kept).\n\nIn this module, we have again a ``settings.py`` file, plus a ``wsgi.py`` file.\nWe will look at the latter in more detail in `Going production`_: the first,\ninstead, is the actual settings module that will be loaded by Django_.\n\nSo what about the settings we defined earlier? Do not fear,\nbecause the buildout created ``settings.py`` will import the module you wrote\nand add to it the ``SECRET_KEY`` setting::\n\n    >>> cat('parts', 'myproject', 'myproject_part_site', 'settings.py')\n    from myproject_site_config.settings import *\n    <BLANKLINE>\n    SECRET_KEY = \"...\"\n    <BLANKLINE>\n    <BLANKLINE>\n\nThis (slightly convoluted) setup exists because a poorly chosen ``SECRET_KEY``\ncan become a security problem (and quite a big one, for pathological cases).\n\nSince it's way too easy to pick a simple one\n(maybe because we can't be bothered to come up with a decent one)\nand even more easy to forget to change it between\ndevelopment and production environment,\nthis recipe generates a long, random key for you.\n\nThis way you can safely omit ``SECRET_KEY`` within your ``settings.py`` file\nand at the same time be completely secure.\n\nThis key is generated only once and is kept\nthrough the various runs of ``bin/buildout``.\nThis is possible because the recipe will first look\nwhether a ``.secret.cfg`` file exists in the buildout root:\nif it exists, it will read it and extract the key from there\n(the file contents are the key itself and a newline).\nIf it doesn't exist, it will generate a new key and write it there.\nTherefore, as long as a ``.secret.cfg`` file exists,\nthe recipe will use the same key throughout the various runs\nof ``bin/buildout``.\n\nProof of the fact is that a ``.secret.cfg`` file exists in our buildout::\n\n    >>> isfile('.secret.cfg')\n    True\n\nComplete example\n----------------\n\nLet's now put into our settings file (``myproject_site_config/settings.py``)\nsome more sane values::\n\n    >>> write('sites', 'myproject_site_config', 'settings.py', '''\n    ... DATABASES = {\n    ...     'default': {\n    ...         'ENGINE': 'django.db.backends.sqlite3',\n    ...         'NAME': 'storage.db'\n    ...     }\n    ... }\n    ... TIME_ZONE = 'Europe/Rome'\n    ... ''')\n\nNow, in order for these settings to take effect,\nwe don't have to re-run buildout,\nas the import that the generated file does will pick them up::\n\n    >>> print system('bin/django diffsettings')\n    DATABASES = {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'storage.db'}}\n    SECRET_KEY = '...'\n    SETTINGS_MODULE = 'myproject_part_site.settings'  ###\n    TIME_ZONE = 'Europe/Rome'\n\nSeems like it worked!\n\nWe decided to put the database in a *SQLite* file named ``storage.db``,\nwhich currently doesn't exist::\n\n    >>> isfile('storage.db')\n    False\n\nLet's now tell Django_ to create the database::\n\n    >>> print system('bin/django syncdb --noinput')\n    Creating tables ...\n    Installing custom SQL ...\n    Installing indexes ...\n    Installed 0 object(s) from 0 fixture(s)\n    <BLANKLINE>\n\nAnd we will see that the database has been created::\n\n    >>> isfile('storage.db')\n    True\n\nDebug mode\n----------\n\nWe can now start developing but, sooner or later,\nwe'll recognize that we haven't set ``DEBUG = True``,\nwhich is fundamental `if your name is not Donald Knuth`_.\n\nWe could add it straight away in ``myproject_site_config/settings.py``,\nbut that might cause problems when we're `Going production`_,\nbecause you definitely want to have ``DEBUG`` and its sisters off\nwhen you're out in the open.\n\nTherefore, another option that we have is to do the following::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... settings-override =\n    ...     DEBUG = True\n    ...     TEMPLATE_DEBUG = True\n    ... ''')\n\nAnything that we put in ``settings-override`` will be appended\nat the end of the buildout-generated ``settings.py``\n(treated as a string, so beware that no correctness checking\nis performed).\nThis allows us to quickly differentiate production and development buildouts\nwithout having the need to come up with two different ``settings.py`` files\n(one for production and one for development).\n\nIf we re-run the buildout and look at the results,\nwe will see that we are now in debug mode::\n\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('parts', 'myproject', 'myproject_part_site', 'settings.py')\n    from myproject_site_config.settings import *\n    <BLANKLINE>\n    SECRET_KEY = \"...\"\n    <BLANKLINE>\n    DEBUG = True\n    TEMPLATE_DEBUG = True\n    <BLANKLINE>\n    >>> print system('bin/django diffsettings')\n    DATABASES = {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'storage.db'}}\n    DEBUG = True\n    SECRET_KEY = '...'\n    SETTINGS_MODULE = 'myproject_part_site.settings'  ###\n    TEMPLATE_DEBUG = True\n    TIME_ZONE = 'Europe/Rome'\n\n.. note::\n   Since this gets appended to the file, be careful that\n   if you do define *and* reference ``DEBUG`` (or any other variable)\n   within the ``settings.py`` file in your full control,\n   our setting it *afterwards* will not affect its value\n   within *your* ``settings.py``.\n   So if in your ``settings.py`` you do ``DEBUG = False``\n   and ``FOOBAR = False``, ``FOOBAR`` will always be false.\n\nOf course, this is not limited to ``DEBUG``, you can use it for example\nto override the ``DATABASES``, ``LOGGING`` and ``CACHES`` settings\nin the production environment without having to create\na whole new ``settings.py`` file.\n\n.. note::\n   Due to buildout's limitations, indentation of ``settings-override``\n   is completely lost. Therefore don't do ``if`` or more complex stuff:\n   if you need to, check out `Advanced usage`_\n\nGoing production\n----------------\n\nAs we saw above, if our development setup doesn't differ too much\nfrom our production setup\n(save for the fact that we use a real cache, a more complex RDBMS, etc)\nthen we can use ``settings-override`` to manage it::\n\n    >>> mkdir('var')\n    >>> mkdir('var', 'log')\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... settings-override =\n    ...     DATABASES = {\n    ...         'default': {\n    ...             'ENGINE': 'django.db.backends.postgresql_psycopg2',\n    ...             'HOST': 'localhost',\n    ...             'PORT': '5432',\n    ...             'NAME': 'mydb',\n    ...             'USER': 'mydb',\n    ...             'PASSWORD': 'secret'\n    ...         }\n    ...     }\n    ...     CACHES = {\n    ...         'default': {\n    ...             'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n    ...             'LOCATION': '127.0.0.1:11211',\n    ...         }\n    ...     }\n    ...     LOGGING = {\n    ...         'version': 1,\n    ...         'disable_existing_loggers': True,\n    ...         'root': { 'level': 'WARNING', 'handlers': ['logfile'], },\n    ...         'formatters': {\n    ...             'verbose': {\n    ...                 'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'\n    ...             },\n    ...         },\n    ...         'handlers': {\n    ...             'logfile': {\n    ...                 'level': 'ERROR',\n    ...                 'class': 'logging.handlers.RotatingFileHandler',\n    ...                 'filename': 'var/log/myproject.log',\n    ...                 'maxBytes': 1024,\n    ...                 'backupCount': 3,\n    ...             },\n    ...             'console': {\n    ...                 'level': 'DEBUG',\n    ...                 'class': 'logging.StreamHandler',\n    ...                 'formatter': 'verbose'\n    ...             }\n    ...         },\n    ...         'loggers': {\n    ...             'django.db.backends': {\n    ...                 'level': 'ERROR',\n    ...                 'handlers': ['console'],\n    ...                 'propagate': False,\n    ...             },\n    ...         },\n    ...     }\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> print system('bin/django diffsettings')\n    CACHES = ...\n    DATABASES = ...\n    LOGGING = ...\n    SECRET_KEY = '...'\n    SETTINGS_MODULE = 'myproject_part_site.settings'  ###\n    TIME_ZONE = 'Europe/Rome'\n\nThis is actually a quite complete (albeit basic) production example,\nand it can still be managed quite well within the buildout.\n\nIf we do have more complex cases, however,\nit's probably better to use `External settings`_.\n\nChanging the binary name\n------------------------\n\nAs we have said before, the name of the generated binary is always ``django``,\nwithout any suffix or prefix.\n\nThe rational for this choice is the following:\n\n  #. Having the script named ``django`` and it being the same\n     no matter how you call the buildout part simplifies\n     getting into development a lot\n     (it's always ``bin/django runserver`` after you run the buildout,\n     and you don't have to go and look how it is named\n     in that particular buildout)\n\n  #. Since in production you will just configure your *WSGI* server\n     to use multiple processes, there are very few reasons\n     to have multiple Django_ parts in your buildout\n\nBut if you really need to have multiple parts,\nthe default behaviour will have one part overwrite the other's script.\nThat's when you need to use the `manage-py-file`_ option,\nwhich allows you to provide a different name\n(say, ``django1`` and ``django2``) for the manage script.\n\nFirst we start by copying the settings of our sample project\nto two ned different locations, ``myproject1`` and ``myproject2``::\n\n    >>> copytree(['sites', 'myproject_site_config'],\n    ...          ['sites', 'myproject1_site_config'])\n    >>> copytree(['sites', 'myproject_site_config'],\n    ...          ['sites', 'myproject2_site_config'])\n\nThen we write a buildout that has *two* parts,\n``myproject1`` and ``myproject2``, and run it::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject1\n    ...     myproject2\n    ...\n    ... [myproject1]\n    ... recipe = djc.recipe2\n    ... manage-py-file = django1\n    ...\n    ... [myproject2]\n    ... recipe = djc.recipe2\n    ... manage-py-file = django2\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject1.\n    ...\n    Installing myproject2.\n    ...\n    <BLANKLINE>\n\nAnd we will see that it has created two distinct scripts::\n\n    >>> ls('bin')\n    -  buildout\n    -  django1\n    -  django2\n\n\nAdvanced usage\n==============\n\nCustom initialization\n---------------------\n\nSometimes, you need to do some magic before Django_ loads everything,\nin order to use certain features.\n\nFor example, Pinax_, a very well known social site framework based on Django_,\nneeds you to perform certain ``sys.path`` magic before initialization.\n\nThis kind of customization can be done in two ways:\n\n  #. By performing those in ``settings.py``\n  #. By altering the manage script (and the *WSGI* one, too)\n\nThe first choice might look simpler but it actually hides much more complexity\nthan it is initially visible.\nThe latter is better but, since the script is generated by buildout,\nwe cannot simply edit that file.\n\nBefore looking at how you actually do it, let's make a premise:\nwe can divide this initialization stuff in two main groups.\n\nThe first and more common group is when you simply need\nto set an environment variable: while this can be achieved\nby doing ``$ MYVAR=value bin/django``, it's not exactly handy in the long run.\n\nAnd here comes `environment-vars`_ to the rescue!\n\nLet's look at a concrete example: running Django_ on `Google App Engine`_.\n`Google App Engine`_ requires you to have a ``GOOGLE_APPENGINE_PROJECT_ROOT``\nenvironment variable set, or nothing will work.\n\nTherefore, in order to add it we would write our buildout as follows,\nwith a list of variables and values (separated by space)\nfor each environment variable we want to set::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... environment-vars =\n    ...     GOOGLE_APPENGINE_PROJECT_ROOT /my/path\n    ... ''')\n\nAnd after running it, we can see that the script correctly initializes\nthe environment variable::\n\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #!...\n    <BLANKLINE>\n    ...\n    <BLANKLINE>\n    import os\n    os.environ[\"GOOGLE_APPENGINE_PROJECT_ROOT\"] = r\"/my/path\"\n    <BLANKLINE>\n    ...\n    <BLANKLINE>\n    os.environ['DJANGO_SETTINGS_MODULE'] = \"myproject_part_site.settings\"\n    if IS_14_PLUS:\n        execute_from_command_line(sys.argv)\n    else:\n        utility = ManagementUtility(sys.argv)\n        utility.execute()\n\nFor the second case, the `initialization`_ option is provided:\nthis allows you to write (in a format similar to doctest)\nthe python code that you need to be executed before Django_ starts.\n\n.. note::\n   The slightly funny *doctest syntax* of this option is to overcome\n   a shortcoming of buildout that will otherwise completely lose indentation.\n\nLet's see how we would make sure that Django_ won't start at all\nif ``1 != 1``::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... initialization =\n    ...     >>> if 1 != 1:\n    ...     ...     raise RuntimeError(\"I can't run on quantum computers\")\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #!...\n    <BLANKLINE>\n    ...\n    <BLANKLINE>\n    if 1 != 1:\n        raise RuntimeError(\"I can't run on quantum computers\")\n    <BLANKLINE>\n    ...\n    <BLANKLINE>\n    os.environ['DJANGO_SETTINGS_MODULE'] = \"myproject_part_site.settings\"\n    if IS_14_PLUS:\n        execute_from_command_line(sys.argv)\n    else:\n        utility = ManagementUtility(sys.argv)\n        utility.execute()\n\n.. note::\n   I really couldn't come up with a better example\n   that would work in tests without having to bring in loads of crap,\n   but I can assure you this feature **is** useful. Really.\n\nMedia and static\n----------------\n\nThis is a bit of personal preference.\nWhen developing upon work started by someone else,\nI find it utterly irritating that the upload doesn't work because,\nafter checking out and running the buildout, I did not do ``$ mkdir media``.\n\nBecause:\n\n  #. I'm getting old and I tend to forget that\n  #. Sometimes it's not ``media``, but ``var/upload/mediafiles``\n     or something else (yes, we programmers tend to express creativity\n     in the most inopportune ways)\n\nThat's why I've added two options that, while not being on by default,\nI wish you have turned on (atleast one of them)\nif I have to work on your buildout.\n\nThe options are `media-directory`_ and `static-directory`_,\nand their values are the path to the media root and the static root\nrespectively.\nWhen they are set, the buildout will create them if they don't exist\nand then append to the settings module the proper ``MEDIA_ROOT``\nand ``STATIC_ROOT`` setting.\n\nLet's see them in action. First we check that we don't have any\n``static`` or ``media`` directory::\n\n    >>> isdir('media')\n    False\n    >>> isdir('static')\n    False\n\nThen write and run the buildout::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... media-directory = media\n    ... static-directory = static\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n\nAnd then see that we have the directories and the settings::\n\n    >>> isdir('media')\n    True\n    >>> isdir('static')\n    True\n    >>> print system('bin/django diffsettings')\n    DATABASES = ...\n    MEDIA_ROOT = '...'\n    SECRET_KEY = '...'\n    SETTINGS_MODULE = 'myproject_part_site.settings'  ###\n    STATIC_ROOT = '...'\n    TIME_ZONE = 'Europe/Rome'\n\nObviously, you do not need to use them together\nbut they can be used independently.\n\nExternal settings\n-----------------\n\nSometimes, one file for all the settings just ain't enough,\nor it might turn out that `settings-override`_ is not quite handy for you.\n\nThat's why this recipe allows you to use as a settings module anything\nthat's in in ``sys.path``.\n\nFor example, suppose we want to put our production settings\nin a file on its own: we might then create a file\nnamed ``sites/myproject_site_config/production.py``\nand use that as settings module.\n\nFirst, let's create the file::\n\n    >>> write('sites', 'myproject_site_config', 'production.py', '''\n    ... from .settings import *\n    ... TIME_ZONE = 'Europe/London'\n    ... ''')\n\nThen we tell the buildout to use the module\n``myproject_site_config.production`` as settings module\ninstead of the default one, through the `settings-module`_ option::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... settings-module = myproject_site_config.production\n    ... ''')\n\n.. note::\n   The module can be anything in ``sys.path``, but here we reused the\n   same directory because whenever `sites-directory`_ exists\n   and regardless of what's in it, it is put on ``sys.path``.\n   You can ofcourse have the settings module in your project egg\n   or whatever else.\n\nAnd we can then run the buildout and see what happened::\n\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> print system('bin/django diffsettings')\n    DATABASES = ...\n    SECRET_KEY = '...'\n    SETTINGS_MODULE = 'myproject_part_site.settings'  ###\n    TIME_ZONE = 'Europe/London'\n\nAnd as you can see, the changes took effect.\n\nOptions reference\n=================\n\neggs\n----\n\nA list of eggs that the generated scripts must have access to.\nThis typically includes your application eggs and their dependencies,\nif the latter are not explicited within the ``setup.py`` file.\n\nThey can be explicited either as a part option::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... eggs = django-gravatar2\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #...\n    <BLANKLINE>\n    <BLANKLINE>\n    import sys\n    sys.path[0:0] = [\n        '.../eggs/django_gravatar2-1.0.4-...egg',\n        ...\n        ]\n    <BLANKLINE>\n    ...\n\nOr as a buildout option::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... eggs = django-gravatar2\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #...\n    <BLANKLINE>\n    <BLANKLINE>\n    import sys\n    sys.path[0:0] = [\n        '.../eggs/django_gravatar2-1.0.4-...egg',\n        ...\n        ]\n    <BLANKLINE>\n    ...\n\nOr both, and they will be merged::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... eggs = South\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... eggs = django-gravatar2\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #...\n    <BLANKLINE>\n    <BLANKLINE>\n    import sys\n    sys.path[0:0] = [\n        '.../eggs/django_gravatar2-1.0.4-...egg',\n        '.../eggs/South-0.7.5-...egg',\n        ...\n        ]\n    <BLANKLINE>\n    ...\n\nenvironment-vars\n----------------\n\nA list of environment variables to set before execution,\neach separated by newline and in the format ``VAR_NAME value``.\n\nSee `Custom initialization`_ for an example.\n\nextra-paths\n-----------\n\nA list of paths, separated by newline,\nthat should be added to ``sys.path`` before the code is executed\n(allowing the discovery of custom modules).\n\nFor example::\n\n    >>> mkdir('custom_modules')\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... extra-paths =\n    ...     custom_modules\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #...\n    <BLANKLINE>\n    <BLANKLINE>\n    import sys\n    sys.path[0:0] = [\n        ...\n        '.../custom_modules',\n        ]\n    <BLANKLINE>\n    ...\n\ninitialization\n--------------\n\nPython code, to be formatted like a doctest,\nthat is to be executed before any initialization happens.\n\nSee `Custom initialization`_ for an example.\n\nmanage-py-file\n--------------\n\nThe name of the generated manage script in ``bin``.\n\nSee `Changing the binary name`_ for an example.\n\nsettings-file\n-------------\n\nThe name of the generated settings file\n(the one that's autogenerated by buildout at each run).\n\nThis option can be quite useful to avoid module name clashes::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... settings-file = configuration.py\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> print system('bin/django diffsettings')\n    DATABASES = ...\n    SECRET_KEY = '...'\n    SETTINGS_MODULE = 'myproject_part_site.configuration'  ###\n    TIME_ZONE = 'Europe/Rome'\n\nsettings-module\n---------------\n\nLoads a custom settings module instead of the conventional one.\n\nSee `External settings`_ for an example.\n\nsettings-override\n-----------------\n\nSpecifies some settings (as python code) to be appended\nto the auto-generated settings file and thus overriding the module-defined ones.\n\nSee `Debug mode`_ for an example.\n\nsites-directory\n---------------\n\nChanges the default location of the conventional configuration location\n(normally the ``sites`` directory).\n\nIt will be appended to ``sys.path``::\n\n    >>> copytree(['sites'], ['mysites'])\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... sites-directory = mysites\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> cat('bin', 'django')\n    #...\n    <BLANKLINE>\n    <BLANKLINE>\n    import sys\n    sys.path[0:0] = [\n        ...\n        '.../mysites',\n        ]\n    <BLANKLINE>\n    ...\n\nstatic-directory\n----------------\n\nSets the location of ``STATIC_ROOT`` and creates it if missing.\n\nSee `Media and static`_.\n\nmedia-directory\n---------------\n\nSame as `static-directory`_ for ``MEDIA_ROOT``.\n\nwsgi-file\n---------\n\nChanges the name of the file that contains the *WSGI* application.\n\nThe purpose is similar to `settings-file`_::\n\n    >>> write('buildout.cfg', '''\n    ... [buildout]\n    ... parts =\n    ...     myproject\n    ...\n    ... [myproject]\n    ... recipe = djc.recipe2\n    ... wsgi-file = wsgiapp.py\n    ... ''')\n    >>> print \"$ bin/buildout\\n\", system(buildout)\n    $ bin/buildout\n    ...\n    Installing myproject.\n    ...\n    <BLANKLINE>\n    >>> ls('parts', 'myproject', 'myproject_part_site')\n    -  __init__.py\n    -  settings.py\n    -  wsgiapp.py\n\n.. _Django: https://djangoproject.com\n.. _`settings module`: https://docs.djangoproject.com/en/dev/topics/settings/\n.. _`if your name is not Donald Knuth`: http://www-cs-faculty.stanford.edu/~knuth/faq.html\n.. _Pinax: http://pinaxproject.com/\n.. _`Google App Engine`: https://developers.google.com/appengine/\n\nContributors\n************\n\n * Simone Deponti <simone.deponti@abstract.it>, Initial Author\n * Bruno Ripa <bruno.ripa@abstract.it>\n * Mikko Ohtamaa (@moo9000)\n * Dimitri Roche\n\nInital developement sponsored by `Abstract Open Solutions`_\n\n.. _`Abstract Open Solutions`: http://www.abstract.it\n\nChange history\n**************\n\n2.1 (2012-07-02)\n================\n\n- Fixed setuptools-git problem.\n\n\n2.0 (2012-07-02)\n================\n\n- Rewrite from `djc.recipe`_ [Simone Deponti]\n\n\n.. _`djc.recipe`: http://pypi.python.org/pypi/djc.recipe",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "UNKNOWN",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://github.com/abstract-open-solutions/djc.recipe2",
        "keywords": "",
        "license": "BSD",
        "maintainer": null,
        "maintainer_email": null,
        "name": "djc.recipe2",
        "package_url": "https://pypi.org/project/djc.recipe2/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/djc.recipe2/",
        "project_urls": {
            "Download": "UNKNOWN",
            "Homepage": "http://github.com/abstract-open-solutions/djc.recipe2"
        },
        "release_url": "https://pypi.org/project/djc.recipe2/2.1/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "A Django buildout recipe",
        "version": "2.1"
    },
    "last_serial": 745193,
    "releases": {
        "2.0": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "4d6475d8aa3ec718c1f04f04edf01360",
                    "sha256": "0c0b98e5ad195fbd0dfc281c51dac6efba020d9d8bf9fd8338a7d7a285eeaf8b"
                },
                "downloads": -1,
                "filename": "djc.recipe2-2.0.zip",
                "has_sig": false,
                "md5_digest": "4d6475d8aa3ec718c1f04f04edf01360",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 25572,
                "upload_time": "2012-07-02T11:09:21",
                "url": "https://files.pythonhosted.org/packages/0a/76/738f73257d7aea17a9b4d376dcd7d2a6956e522deaa46748b8eaed8b8684/djc.recipe2-2.0.zip"
            }
        ],
        "2.1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "b1aa7bb9fcaa5b1a436784d1e79485a9",
                    "sha256": "c1eaab1383284bb55c230a841765ccd3450343cbc31c7146178038066c1e18c0"
                },
                "downloads": -1,
                "filename": "djc.recipe2-2.1.zip",
                "has_sig": false,
                "md5_digest": "b1aa7bb9fcaa5b1a436784d1e79485a9",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 38166,
                "upload_time": "2012-07-02T11:17:17",
                "url": "https://files.pythonhosted.org/packages/03/03/c722cda11ad0338f379ebd81fc252a283e4d91060796ea5350cf74cc0ffa/djc.recipe2-2.1.zip"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "b1aa7bb9fcaa5b1a436784d1e79485a9",
                "sha256": "c1eaab1383284bb55c230a841765ccd3450343cbc31c7146178038066c1e18c0"
            },
            "downloads": -1,
            "filename": "djc.recipe2-2.1.zip",
            "has_sig": false,
            "md5_digest": "b1aa7bb9fcaa5b1a436784d1e79485a9",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 38166,
            "upload_time": "2012-07-02T11:17:17",
            "url": "https://files.pythonhosted.org/packages/03/03/c722cda11ad0338f379ebd81fc252a283e4d91060796ea5350cf74cc0ffa/djc.recipe2-2.1.zip"
        }
    ]
}