Commits

Ilkka Hakkari committed 2335581

Updated readme

  • Participants
  • Parent commits 3ccdde3

Comments (0)

Files changed (1)

 Django project skeleton
 ***********************
 
-Django has all the necessary tools to easily create a 
+Django has all the necessary tools to easily create a
 project, and your first app. But first you need to have
 Django installed. Do you want to install it system wide?
 How about all the dependencies your project will have?
 And then there is the release pain when you want to relese
-one of your Django apps to the public. 
+one of your Django apps to the public.
 
-The benefit in this skeleton is that it makes development 
-of re-usable Django apps really easy. 
+The benefit in this skeleton is that it makes development
+of re-usable Django apps really easy.
 
 Features in this skeleton:
 
 * Setting files for development and production
 * django-sentry for error reporting
 * South for database migrations
-* Additions to runserver command
+* Supervisord for process management
 
 This work is based on the ideas presented in
 `Developing Django apps with zc.buildout`__ by Jacob Kaplan-Moss.
 =======================
 
 The project bootstrapping, deployment and sandboxing is handled by
-`Buildout`__. 
+`Buildout`__.
 
 __ http://www.buildout.org/
 
-There's also ``bootstrap.py`` in the repo which can be used to 
-install buildout locally in the project directory if you don't want to 
-install it system wide. 
+There's also ``bootstrap.py`` in the repo which can be used to
+install buildout locally in the project directory if you don't want to
+install it system wide.
 
-Buildout handles downloading and installing of all dependencies the 
+Buildout handles downloading and installing of all dependencies the
 project needs. Dependencies can be written in the ``buildout.cfg``
 file, but Buildout is so clever that it collects the dependencies also
-from the apps we are developing. This makes it easy to develop 
+from the apps we are developing. This makes it easy to develop
 self-containing apps even when they are in the same directory tree with
 the rest of the project.
 
 Django is not specified as a dependency in the ``buildout.cfg``
-file as it is provided by `djangorecipe`__. 
+file as it is provided by `djangorecipe`__.
 
 __ http://pypi.python.org/pypi/djangorecipe
 
 Developing multiple apps
 ========================
 
-At first the coding begins in a single repo, just like the Django 
-tutorials explain. The developer doesn't need to pay any 
-attention to the fact that all apps are also python eggs. 
-When one of the apps reach a point that it is needed in another project, 
-then that directory is split into a separate repository. 
+At first the coding begins in a single repo, just like the Django
+tutorials explain. The developer doesn't need to pay any
+attention to the fact that all apps are also python eggs.
+When one of the apps reach a point that it is needed in another project,
+then that directory is split into a separate repository.
 Public releases are also easy as the egg machinery is there from the
-beginning. 
+beginning.
 
-Buildout makes it easy to switch between installing an egg from 
+Buildout makes it easy to switch between installing an egg from
 PyPi and using local source tree for the egg. When the egg is listed
 in the ``develop`` list in the ``buildout.cfg`` file the local
 copy of the source is used, otherwise it is searched from PyPi.
       │   └── foo
       └── runserver
 
-The ``src`` directory contains the eggs. Directories ``src/foo`` 
-and ``src/runserver`` have the ``setup.py`` file needed by all 
-Python eggs. The ``foo`` app here is a placeholder, and a template, 
-for your code. 
+The ``src`` directory contains the eggs. Directories ``src/foo``
+and ``src/runserver`` have the ``setup.py`` file needed by all
+Python eggs. The ``foo`` app here is a placeholder, and a template,
+for your code.
 
 Also the ``project`` directory is in the ``PYTHONPATH`` so
-it is possible to put views and other misc stuff in there if you 
-need. 
+it is possible to put views and other misc stuff in there if you
+need.
 
 Django settings
 ===============
 Usually development and production environments are little
 different. Sometimes more. But always it is best to have
 separate configuration to these two environments. As django
-settings file is normal python source file it is easy to 
-customize the way it is loaded. 
+settings file is normal python source file it is easy to
+customize the way it is loaded.
 
-This skeleton uses a three file system. There is 
-``project/settings.py`` which contains the basics and 
-all common settings to other variants. Then files 
-``project/production.py`` and ``project/development.py`` 
+This skeleton uses a three file system. There is
+``project/settings.py`` which contains the basics and
+all common settings to other variants. Then files
+``project/production.py`` and ``project/development.py``
 start with a line ``from project.settings import *``. After that
-line it is just matter of overriding the defaults. 
-
-Additions to the runserver command
-----------------------------------
-
-By default the Django runserver command serves admin media from
-the Django distribution. The directory can be changed, but only
-with command line switch. 
-
-In the app ``src/runserver`` is an addition which adds
-a settings variable ``RUNSERVER_MEDIA_PATH`` for changing
-the path. It is enabled only in the development build in this
-skeleton as it only affects the runserver command.
+line it is just matter of overriding the defaults.
 
 Monitoring and error reporting
 ==============================
 
 We use `django-sentry`__ for  monitoring and error logging.
-In this skeleton it is configured as a client only 
-to send exceptions and all log messages to separate 
-sentry instance. You can change this behaviour in 
-``project/production.py`` settings file. 
+In this skeleton it is configured as a client only
+to send exceptions and all log messages to separate
+sentry instance. You can change this behaviour in
+``project/production.py`` settings file.
 
 __ https://github.com/dcramer/django-sentry
 
 ==========
 
 To actually use this skeleton you should rename the parts that are now
-called ``foo``. Mainly these are the egg name ``django-foo`` and the 
-Python module ``foo`` the egg contains. 
-
-These directories: 
-
- * src/foo
- * src/foo/foo
-
-And then these locations in the files:
-
- * buildout.cfg:4:  src/foo
- * buildout.cfg:7:  django-foo
- * buildout.cfg:23:test = foo
- * project/settings.py:64:    'foo',
- * project/production.py:11:    'NAME': os.path.join(BASEDIR, '..', '..', 'databases', 'foo.db'),
- * src/foo/setup.py:5:    name = "django-foo",
- * src/foo/setup.py:7:    url = 'http://example.com/django-foo',
+called ``foo``. Mainly these are the egg name ``django-foo`` and the
+Python module ``foo`` the egg contains.
 
 Starting the Django instance
 ----------------------------
   bin/django syncdb
   bin/django runserver
 
-In the syncdb phase it asks for the admin account. 
-After that the development server should be running 
+In the syncdb phase it asks for the admin account.
+After that the development server should be running
 and you can log in to http://127.0.0.1:8000/admin