include copy of django_extension, dont install django from git

contrib/django_extensions/docs/AUTHORS

@@ -0,0 +1,21 @@
+The following individuals have contributed to this project
+
+Antonio Cavedoni - For the GraphViz stuff (http://cavedoni.com/)
+Ludvig Ericson (toxic)
+Collin Grady (magus)
+Gabriel Grant (gabrielgrant)
+Rob Hudson (robhudson)
+Jannis Leidel (leidel)
+Brian Rosner (brosner)
+Michael Trier (empty)
+Doug Napoleone (dougn)
+Bas van Oostveen (trbs)
+David Krauth (dakrauth)
+Will Larson (lethain) - For syntax_color template filters.
+Patrick Altman (paltman) - Patched sync_media_s3
+Chris Beaven (smileychris) - widont filter
+qMax - various graph_model patches
+Tyson Clugg (tclugg) - Patched sqldiff
+Domen Kožar (iElectric) - staticfiles patch improvement
+quinox - original staticfiles patch
+Camilo Nova (camilonova)

contrib/django_extensions/docs/Makefile

@@ -0,0 +1,75 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d _build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html web pickle htmlhelp latex changes linkcheck
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html      to make standalone HTML files"
+	@echo "  pickle    to make pickle files"
+	@echo "  json      to make JSON files"
+	@echo "  htmlhelp  to make HTML files and a HTML help project"
+	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  changes   to make an overview over all changed/added/deprecated items"
+	@echo "  linkcheck to check all external links for integrity"
+
+clean:
+	-rm -rf _build/*
+
+html:
+	mkdir -p _build/html _build/doctrees _static
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) _build/html
+	@echo
+	@echo "Build finished. The HTML pages are in _build/html."
+
+pickle:
+	mkdir -p _build/pickle _build/doctrees
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) _build/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+web: pickle
+
+json:
+	mkdir -p _build/json _build/doctrees
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) _build/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	mkdir -p _build/htmlhelp _build/doctrees
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) _build/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in _build/htmlhelp."
+
+latex:
+	mkdir -p _build/latex _build/doctrees
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in _build/latex."
+	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+	      "run these through (pdf)latex."
+
+changes:
+	mkdir -p _build/changes _build/doctrees
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) _build/changes
+	@echo
+	@echo "The overview file is in _build/changes."
+
+linkcheck:
+	mkdir -p _build/linkcheck _build/doctrees
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) _build/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in _build/linkcheck/output.txt."

contrib/django_extensions/docs/admin_extensions.rst

@@ -0,0 +1,10 @@
+Current Admin Extensions
+========================
+
+:synopsis: Current Field Extensions
+
+
+* *ForeignKeyAutocompleteAdmin* - ForeignKeyAutocompleteAdmin will enable the
+  admin app to show ForeignKey fields with an search input field. The search
+  field is rendered by the ForeignKeySearchInput form widget and uses jQuery
+  to do configureable autocompletion.

contrib/django_extensions/docs/command_extension_ideas.rst

@@ -0,0 +1,7 @@
+Ideas for New Command Extensions
+================================
+
+:synopsis: Here are some ideas for some future command extensions.
+
+* create form/manager for App
+* CSS and JS concatenation and minification scripts

contrib/django_extensions/docs/command_extensions.rst

@@ -0,0 +1,95 @@
+Current Command Extensions
+==========================
+
+:synopsis: Current Command Extensions
+
+* :doc:`shell_plus` - An enhanced version of the Django shell.  It will autoload
+  all your models making it easy to work with the ORM right away.
+
+* `create_app`_ - Creates an application directory structure for the specified
+  app name.  This command allows you to specify the --template option where you
+  can indicate a template directory structure to use as your default.
+
+* *create_command* - Creates a command extension directory structure within the
+  specified application.  This makes it easy to get started with adding a
+  command extension to your application.
+
+* *create_jobs* - Creates a Django jobs command directory structure for the
+  given app name in the current directory.  This is part of the impressive jobs
+  system.
+
+* *create_superuser* - Makes it easy to create a superuser for the
+  django.contrib.auth.
+
+* *describe_form* - Used to display a form definition for a model.  Copy and
+  paste the contents into your forms.py and you're ready to go.
+
+* :doc:`dumpscript <dumpscript>` - Generates a Python script that will
+  repopulate the database using objects. The advantage of this approach is that
+  it is easy to understand, and more flexible than directly populating the
+  database, or using XML.
+
+* `export_emails`_ - export the email addresses for your
+  users in one of many formats.  Currently supports Address, Google, Outlook,
+  LinkedIn, and VCard formats.
+
+* *generate_secret_key* - Creates a new secret key that you can put in your
+  settings.py module.
+
+* `graph_models`_ - Creates a GraphViz_ dot file.  You need
+  to send this output to a file yourself.  Great for graphing your models. Pass
+  multiple application names to combine all the models into a single dot file.
+
+* *mail_debug* - Starts a mail server which echos out the contents of the email
+  instead of sending it.
+
+* *passwd* - Makes it easy to reset a user's password.
+
+* `print_settings`_ - Similar to ``diffsettings`` but shows *all* active Django settings.
+
+* *print_user_for_session* - Print the user information for the provided
+  session key. this is very helpful when trying to track down the person who
+  experienced a site crash.
+
+* *reset_db* - Resets a database (currently sqlite3, mysql, postgres).
+
+* *runjob* - Run a single maintenance job.  Part of the jobs system.
+
+* *runjobs* - Runs scheduled maintenance jobs. Specify hourly, daily, weekly,
+  monthly.  Part of the jobs system.
+
+* :doc:`runprofileserver <runprofileserver>` - Starts *runserver* with hotshot/profiling tools enabled.
+  I haven't had a chance to check this one out, but it looks really cool.
+
+* `runscript`_ - Runs a script in the django context.
+
+* `runserver_plus`_ - The standard runserver stuff but with
+  the Werkzeug debugger baked in. Requires Werkzeug_. This one kicks ass.
+
+* *set_fake_passwords* -  Sets all user passwords to a common value (*password* by default). *DEBUG only*.
+
+* *show_urls* - Displays the url routes that are defined in your project. Very
+  crude at this point.
+
+* :doc:`sqldiff` - Prints the (approximated) difference between an apps models and
+  what is in the database.  This is very nice, but also very experimental at
+  the moment.  It can not catch everything but it's a great sanity check.
+
+* :doc:`sqlcreate` - Generates the SQL to create your database for you, as specified
+  in settings.py.
+
+* `sync_s3`_ - Copies files found in settings.MEDIA_ROOT to S3.
+  Optionally can also gzip CSS and Javascript files and set the
+  Content-Encoding header, and also set a far future expires header for browser
+  caching.
+
+
+.. _`create_app`: create_app.html
+.. _`export_emails`: export_emails.html
+.. _`graph_models`: graph_models.html
+.. _`print_settings`: print_settings.html
+.. _`runscript`: runscript.html
+.. _`runserver_plus`: runserver_plus.html
+.. _`sync_s3`: sync_s3.html
+.. _GraphViz: http://www.graphviz.org/
+.. _Werkzeug: http://werkzeug.pocoo.org/

contrib/django_extensions/docs/conf.py

@@ -0,0 +1,194 @@
+# -*- coding: utf-8 -*-
+#
+# django-extensions documentation build configuration file, created by
+# sphinx-quickstart on Wed Apr  1 20:39:40 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+#import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.append(os.path.abspath('.'))
+
+# -- General configuration -----------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'django-extensions'
+copyright = u'Copyright (C) 2008, 2009, 2010, 2011, 2012, 2013 Michael Trier, Bas van Oostveen and contributors'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '1.2'
+# The full version, including alpha/beta/rc tags.
+release = '1.2.2'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# List of directories, relative to source directory, that shouldn't be searched
+# for source files.
+exclude_trees = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  Major themes that come with
+# Sphinx are currently 'default' and 'sphinxdoc'.
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_use_modindex = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = ''
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'django-extensionsdoc'
+
+
+# -- Options for LaTeX output --------------------------------------------------
+
+# The paper size ('letter' or 'a4').
+#latex_paper_size = 'letter'
+
+# The font size ('10pt', '11pt' or '12pt').
+#latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+latex_documents = [(
+    'index', 'django-extensions.tex', u'django-extensions Documentation',
+    u'Michael Trier, Bas van Oostveen, and contributors', 'manual'
+), ]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_use_modindex = True

contrib/django_extensions/docs/create_app.rst

@@ -0,0 +1,41 @@
+create_app
+==========
+
+:synopsis: Creates an application directory structure for the specified application name.
+
+This command allows you to specify the --template option where you can indicate
+a template directory structure to use as your default.
+
+The --diagram option generates the models.py and admin.py from a .dia file.
+
+
+Example Usage
+-------------
+
+All examples assume your current directory is the project directory and
+settings.py is under it.
+
+::
+
+  # Get command help
+  ./manage.py create_app --help
+
+::
+
+  # Generate models.py and admin.py from [APP_NAME].dia file. This file should
+  # be placed in the settings.py directory.
+  ./manage.py create_app -d APP_NAME
+
+
+Example generated from sample.dia
+---------------------------------
+
+::
+
+  ./manage.py create_app --diagram=sample.dia webdata
+
+-d switch or --diagram option use dia2django_ to generate models.py and is
+better documented in `django wiki`_.
+
+.. _dia2django: https://svn.devnull.li/main/pythonware/dia2django/trunk/doc/
+.. _`django wiki`: http://code.djangoproject.com/wiki/Dia2Django

contrib/django_extensions/docs/creating_release.txt

@@ -0,0 +1,58 @@
+Creating a release
+==================
+
+:synopsis: Creating a django-extensions release
+
+
+How to make a new release
+-------------------------
+
+Get a fresh copy::
+
+  $ git clone git@github.com:django-extensions/django-extensions.git
+  $ cd django-extensions
+
+Run tests::
+
+  $ python run_tests.py
+
+Change version numbers in django_extensions/__init__.py and docs/conf.py::
+
+  $ vi django_extensions/__init__.py              (1 occurance)
+  $ vi docs/conf.py                              (2 occurances)
+  $ git commit -a -m v0.4.1
+
+Tag it::
+
+  $ git tag 0.4.1
+
+Prepare the release tarball::
+
+  $ python ./setup.py sdist
+
+Upload release to pypi::
+
+  $ python ./setup.py register
+  $ python ./setup.py sdist upload -s
+
+Upload new documentation to pypi::
+
+  $ cd docs
+  $ make html
+  $ cd _build/html
+  $ zip -r9v ../django_extensions_docs.zip *
+
+Now goto http://pypi.python.org, login and edit the django_extensions package.
+At the bottom of the page your can upload documentation. Click browse, select
+the zip file and hit "Upload Documentation".
+
+Bumb version number to new in-development pre version::
+
+  $ vi django_extensions/__init__.py
+  $ git commit -a -m 'bumped version number'
+
+Push changes back to github::
+
+  $ git push --tags
+  $ git push
+

contrib/django_extensions/docs/dumpscript.rst

@@ -0,0 +1,101 @@
+dumpscript
+==========
+
+:synopsis: Generates a standalone Python script that will repopulate the database using objects.
+
+The `dumpscript` command generates a standalone Python script that will
+repopulate the database using objects. The advantage of this approach is that
+it is easy to understand, and more flexible than directly populating the
+database, or using XML.
+
+Why?
+----
+
+There are a few benefits to this:
+
+* less drama with model evolution: foreign keys handled naturally without IDs,
+  new and removed columns are ignored
+* edit script to create 1,000s of generated entries using for loops, generated
+  names, python modules etc.
+
+For example, an edited script can populate the database with test data::
+
+  for i in xrange(2000):
+      poll = Poll()
+      poll.question = "Question #%d" % i
+      poll.pub_date = date(2001,01,01) + timedelta(days=i)
+      poll.save()
+
+Real databases will probably be bigger and more complicated, and so it is useful
+to enter some values using the admin interface and then edit the generated
+scripts.
+
+
+Features
+--------
+
+* *ForeignKey* and *ManyToManyFields* (using python variables, not object IDs)
+* Self-referencing *ForeignKey* (and M2M) fields
+* Sub-classed models
+* *ContentType* fields and generic relationships (but see issue 43)
+* Recursive references
+* *AutoFields* are excluded
+* Parent models are only included when no other child model links to it
+* Individual models can be referenced
+
+
+What it can't do (yet!)
+-----------------------
+
+* Ideal handling of generic relationships (ie no *AutoField* references):
+  issue 43
+* Intermediate join tables: issue 48
+* GIS fields: issue 72
+
+
+How?
+----
+
+To dump the data from all the models in a given Django app (`appname`)::
+
+  $ ./manage.py dumpscript appname > scripts/testdata.py
+
+To dump the data from just a single model (`appname.ModelName`)::
+
+  $ ./manage.py dumpscript appname.ModelName > scripts/testdata.py
+
+To reset a given app, and reload with the saved data::
+
+  $ ./manage.py reset appname
+  $ ./manage.py runscript testdata
+
+Note: Runscript needs *scripts* to be a module, so create the directory and a
+*__init__.py* file.
+
+
+Caveats
+-------
+
+Naming conflicts
+~~~~~~~~~~~~~~~~
+
+Please take care that when naming the output files these filenames do not
+clash with other names in your import path. If for example the appname is
+the same as the script name then this can cause an importerror.
+
+Since instead of importing the application modules it tries to load the
+modules from the dumpscript file itself.
+
+Examples::
+
+  # Wrong
+  $ ./manage.py dumpscript appname > dumps/appname.py
+  
+  # Right
+  $ ./manage.py dumpscript appname > dumps/appname_all.py
+  
+  # Right
+  $ ./manage.py dumpscript appname.Somemodel > dumps/appname_somemodel.py
+
+
+

contrib/django_extensions/docs/export_emails.rst

@@ -0,0 +1,81 @@
+export_emails
+=============
+
+:synopsis: export the email addresses for your users in one of many formats
+
+Most Django sites include a registered user base. There are times when you
+would like to import these e-mail addresses into other systems (generic mail
+program, GMail, google docs invites, give edit permissions, LinkedLn Group
+pre-approved listing). The export_emails command extension gives you this
+ability. The users exported can be filtered by Group name association.
+
+
+Example Usage
+-------------
+
+::
+
+  # Export all the addresses in the '"First Last" <my@addr.com>;' format.
+  $ ./manage.py export_emails > addresses.txt
+
+::
+
+  # Export users from the group 'Attendees' in the linked in pre-approve Group csv format.
+  $ ./manage.py export_emails -g Attendees -f linkedin pycon08.csv
+
+::
+
+  # Create a csv file importable by GMail or Google Docs
+  $ ./manage.py export_emails --format=google google.csv
+
+
+Current Supported Formats
+-------------------------
+
+address
+^^^^^^^
+
+This is the default basic text format. Each entry is on its own line in the
+format::
+
+  "First Last" <user@host.com>;
+
+This can be used with all known mail programs (that I know about anyway).
+
+
+google
+^^^^^^
+
+A CSV (comma separated value) format which google applications can import.
+This can be used to import directly into GMail, a GMail mailing group, Google
+Docs invite (to read), Google Docs grant edit permissions, Google Calendar
+invites, etc, etc, etc.
+
+Only two columns are supplied. One for the persons name and the e-mail address.
+This is also nice for importing into spreadsheets.
+
+
+outlook
+^^^^^^^
+
+A CSV (comma separated value) format which outlook can parse and import.
+Supplies all the columns that Outlook 'requires', but only the name and e-mail
+address are supplied.
+
+
+linkedin
+^^^^^^^^
+
+A CSV (comma separated value) format which can be imported by `LinkedIn Groups`_
+to pre-approve a list of people for joining the group.
+
+This supplies 3 columns: First name, last name, and e-mail address. This is the
+best generic csv file for importing into spreadsheets as well.
+
+
+vcard
+^^^^^
+
+A vCard format which Apple Address Book can parse and import.
+
+.. _`LinkedIn Groups`: http://www.linkedin.com/static?key=groups_info

contrib/django_extensions/docs/field_extensions.rst

@@ -0,0 +1,27 @@
+Field Extensions
+================
+
+:synopsis: Current Field Extensions
+
+
+Current Database Model Field Extensions
+---------------------------------------
+
+* *AutoSlugField* - AutoSlugfield will automatically create a unique slug
+  increasing an appended number on the slug until it is unique. Inspired by
+  SmileyChris' Unique Slugify snippet.
+
+* *CreationDateTimeField* - DateTimeField that will automatically set it's date
+  when the object is first saved to the database. Works in the same way as the
+  deprecated auto_now_add keyword.
+
+* *ModificationDateTimeField* - DateTimeField that will automatically set it's
+  date when an object is saved to the database. Works in the same way as the
+  deprecated auto_now keyword.
+
+* *UUIDField* - UUIDField for Django, supports all uuid versions which are
+  natively supported by the uuid python module.
+  
+* *EncryptedCharField* - CharField which transparently encrypts its value as it goes in and out of the database.  Encryption is handled by `Keyczar <http://www.keyczar.org/>`_.  To use this field you must have Keyczar installed, have generated a primary encryption key, and have ``settings.KEYS_DIR`` set to the full path of your keys directory.
+
+* *EncryptedTextField* - CharField which transparently encrypts its value as it goes in and out of the database.  Encryption is handled by `Keyczar <http://www.keyczar.org/>`_.  To use this field you must have Keyczar installed, have generated a primary encryption key, and have ``settings.KEYS_DIR`` set to the full path of your keys directory.

contrib/django_extensions/docs/graph_models.rst

@@ -0,0 +1,88 @@
+Graph models
+============
+
+:synopsis: Renders a graphical overview of your project or specified apps.
+
+Creates a GraphViz_ dot file for the specified app names based on their models.py.
+You can pass multiple app names and they will all be combined into a single model.
+Output is usually directed to a dot file.
+
+There several options available like: grouping models, including inheritance,
+excluding models and columns and changing the layout when rendering to an output
+image.
+
+With the latest revisions it's also possible to specify an output file if
+pygraphviz_ is installed and render directly to an image or other supported
+file-type.
+
+
+Selecting a library
+-------------------
+
+You need to select the library to generate the image, you can do so by passing
+the --pygraphviz or --pydot parameters depending on the library you want to use.
+
+When neither of the command line parameters are given the default is to try and load
+pygraphviz or pydot (in that order) to generate the image.
+
+To install pygraphviz you usually need to run this command:
+
+::
+  $ pip install pygraphviz
+
+It is possible you can't install it because it needs some C extensions to build, you
+can try other methods to install or you can use PyDot.
+
+To install pydot you need to run this command:
+
+::
+  $ pip install pyparsing==1.5.7
+  $ pip install pydot
+
+Installation should be fast and easy, remember to install this exact version of
+pyparsing, otherwise it's possible you get this error:
+
+    Couldn't import dot_parser, loading of dot files will not be possible.
+
+
+Default Settings
+----------------
+
+The option GRAPH_MODELS = {} can be used in the settings file to specify default options::
+
+  GRAPH_MODELS = {
+    'all_applications': True,
+    'group_models': True,
+  }
+
+It uses the same names as on the command line only with the leading two dashes removed and
+the other dashes replaced by underscores.
+
+
+Example Usage
+-------------
+
+With *django-extensions* installed you can create a dot-file or an
+image by using the *graph_models* command. Like used in the following examples::
+
+  # Create a dot file
+  $ ./manage.py graph_models -a > my_project.dot
+
+::
+
+  # Create a PNG image file called my_project_visualized.png with application grouping
+  $ ./manage.py graph_models -a -g -o my_project_visualized.png
+
+  # Same example but with explicitly selecting pygraphviz or pydot
+  $ ./manage.py graph_models --pygraphviz -a -g -o my_project_visualized.png
+  $ ./manage.py graph_models --pydot -a -g -o my_project_visualized.png
+
+::
+
+  # Create a dot file for only the 'foo' and 'bar' applications of your project
+  $ ./manage.py graph_models foo bar > my_project.dot
+
+
+.. _GraphViz: http://www.graphviz.org/
+.. _pygraphviz: https://networkx.lanl.gov/wiki/pygraphviz
+.. _pydot: https://pypi.python.org/pypi/pydot

contrib/django_extensions/docs/index.rst

@@ -0,0 +1,79 @@
+.. django-extensions documentation master file, created by
+   sphinx-quickstart on Wed Apr  1 20:39:40 2009.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Welcome to django-extensions's documentation!
+=============================================
+
+Django Extensions is a collection of custom extensions for the Django Framework.
+
+These include management commands, additional database field, admin extensions and
+much more.
+
+Getting Started
+===============
+
+The easiest way to figure out what Django Extensions are all about is to watch the `excellent screencast by Eric Holscher`__. In a couple minutes Eric walks you through a half a dozen command extensions.
+
+Getting it
+==========
+
+You can get Django Extensions by using pip or easy_install::
+
+ $ pip install django-extensions
+ or
+ $ easy_install django-extensions
+
+If you want to install it from source, grab the git repository and run setup.py::
+
+ $ git clone git://github.com/django-extensions/django-extensions.git
+ $ cd django-extensions
+ $ python setup.py install
+
+For more detailed instructions check out our :doc:`installation_instructions`. Enjoy.
+
+Compatibility with versions of Python and Django
+=================================================
+
+We try to follow the Django guidelines for supported Python and Django versions.
+
+This might mean the django-extensions may work with older or unsupported versions but we do not garantee it and most likely will not fix bugs related to incompatibilities with older versions.
+
+At the time of writing we require at least Python 2.5.
+
+Contents
+========
+
+.. toctree::
+   :maxdepth: 3
+
+   installation_instructions
+   command_extensions
+   command_extension_ideas
+   admin_extensions
+   shell_plus
+   create_app
+   dumpscript
+   runscript
+   export_emails
+   field_extensions
+   graph_models
+   jobs_scheduling
+   model_extensions
+   namespace_proposal
+   print_settings
+   runprofileserver
+   runserver_plus
+   sync_s3
+   sqldiff
+   sqlcreate
+   validate_templates
+
+
+Indices and tables
+==================
+
+* :ref:`search`
+
+__ http://ericholscher.com/blog/2008/sep/12/screencast-django-command-extensions/

contrib/django_extensions/docs/installation_instructions.rst

@@ -0,0 +1,100 @@
+Installation instructions
+=========================
+
+:synopsis: Installing django-extensions
+
+
+Download and installation
+-------------------------
+
+Pip and easy_install
+^^^^^^^^^^^^^^^^^^^^
+
+You can use pip or easy_install to install django-extensions::
+
+  $ pip install django-extensions
+
+or::
+
+  $ easy_install django-extensions
+
+Download
+^^^^^^^^
+
+Download the latest packaged version from
+http://pypi.python.org/pypi/django-extensions/ and unpack it. Inside is a
+script called setup.py. Enter this command::
+
+  python setup.py install
+
+...and the package will install automatically.
+
+Installation
+^^^^^^^^^^^^
+
+You will need to add the *django_extensions* application to the INSTALLED_APPS
+setting of your Django project *settings.py* file.::
+
+  INSTALLED_APPS = (
+      ...
+      'django_extensions',
+  )
+
+This will make sure that Django finds the additional management commands
+provided by *django-extensions*.
+
+The next time you invoke *./manage.py help* you should be able to see all the
+newly available commands.
+
+Some command's or option's require additional applications or python libraries,
+for example:
+
+  * 'export_emails' will require the *python vobject* module to create vcard
+    files.
+  * 'graph_models' requires *pygraphviz* to render directly to image file.
+
+If the given application or python library is not installed on your system (or
+not in the python path) the executed command will raise an exception and inform
+you of the missing dependency.
+
+Version Control
+---------------
+
+Django-extensions is hosted on github::
+
+ https://github.com/django-extensions/django-extensions
+
+Source code can be accessed by performing a Git clone.
+
+Tracking the development version of *django command extensions* should be
+pretty stable and will keep you up-to-date with the latests fixes.
+
+The following command will check the application's source code out to a
+directory called *django-extensions*:
+
+Git::
+
+  git clone git://github.com/django-extensions/django-extensions.git
+
+You should either install the resulting project with *python setup.py install*
+or put it the *extensions* directory into your PYTHONPATH. The most common way
+is to symlink (junction, if you're on Windows) the extensions directory inside
+a directory which is on your PYTHONPATH, such as your Python installation's
+site-packages directory.
+
+::
+
+  ln -sf /full/path/to/django-extensions/django_extensions /usr/lib/python2.7/site-packages/django_extensions
+
+You can verify that the application is available on your PYTHONPATH by opening a Python interpreter and entering the following commands:
+
+::
+
+  >>> import django_extensions
+  >>> django_extensions.VERSION
+  (0, 8)
+
+Keep in mind that the current code in the git repository may be different from the
+packaged release. It may contain bugs and backwards-incompatible changes but most
+likely also new goodies to play with.
+

contrib/django_extensions/docs/jobs_scheduling.rst

@@ -0,0 +1,44 @@
+Jobs scheduling
+===============
+
+:synopsis: Documentation on creating/using jobs in Django-extensions
+
+
+JobsScheduling
+--------------
+
+
+This page is very much; Work in Progress
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Creating jobs works much like management commands work in Django.
+Use create_jobs to make a 'jobs' directory inside of an application.
+After that create one python file per job.
+
+Some simple examples are provided by the django_extensions.jobs package.
+
+A job is a python script with a mandatory Job class which extends from
+HourlyJob, DailyJob, WeeklyJob or MonthlyJob. It has one method that must be
+implemented called 'execute', which is called when the job is ran.
+
+The following commands are related to jobs:
+
+* create_jobs, created the directory structure for jobs
+* runjob, runs a single job
+* runjobs, run all hourly/daily/weekly/monthly jobs
+
+Use "runjob(s) -l" to list all jobs recognized.
+
+Jobs do not run automatically !
+
+You must either run a job by hand, with which you can specify the exact time on
+which the command is ran, or put something like the following lines in your
+crontab file.
+
+@hourly /path/to/my/project/manage.py runjobs hourly
+
+@daily /path/to/my/project/manage.py runjobs daily
+
+@weekly /path/to/my/project/manage.py runjobs weekly
+
+@monthly /path/to/my/project/manage.py runjobs monthly

contrib/django_extensions/docs/model_extensions.rst

@@ -0,0 +1,11 @@
+Model extensions
+================
+
+:synopsis: Current Model Extensions
+
+
+Current Database Model Extensions
+---------------------------------
+
+* *TimeStampedModel* - TimeStampedModel An abstract base class model that
+  provides self-managed "created" and "modified" fields.

contrib/django_extensions/docs/namespace_proposal.rst

@@ -0,0 +1,29 @@
+Namespace proposal
+==================
+
+:synopsis: Namespace Proposal
+
+
+Introduction
+------------
+
+Please change / write your proposal for splitting django_extensions into
+namespaces here.
+
+
+Proposal of a Namespace
+-----------------------
+
+Rough proposal for splitting into functional parts:
+
+* django_extensions.commands (20% that everbody uses / production)
+* django_extensions.commands.development (everything development)
+* django_extensions.commands.extra (not fitting about category's?)
+* django_extensions.db
+* django_extensions.templates
+* django_extensions.jobs
+
+The db part should be okey where it is right now. Cause it's only used when
+somebody explicitly imports::
+
+  from django_extensions.db.models import something

contrib/django_extensions/docs/print_settings.rst

@@ -0,0 +1,55 @@
+print_settings
+==============
+
+:synopsis: Django managment command similar to ``diffsettings`` but shows *all* active Django settings.
+
+
+Introduction
+------------
+
+Django comes with a ``diffsettings`` command that shows how your project's
+settings differ from the Django defaults.  Sometimes it is useful to just see
+*all* the settings that are in effect for your project. This is particularly
+true if you have a more complex system for settings than just a single
+:file:`settings.py` file. For example, you might have settings files that
+import other settings file, such as dev, test, and production settings files
+that source a base settings file.
+
+This command also supports dumping the data in a few different formats.
+
+More Info
+---------------
+
+The simplest way to run it is with no arguments::
+
+    $ python manage.py print_settings
+
+Some other variations::
+
+    $ python manage.py print_settings --format=json
+    $ python manage.py print_settings --format=yaml    # Requires PyYAML
+
+For more info, take a look at the built-in help::
+
+    $ python manage.py print_settings --help
+    Usage: manage.py print_settings [options]
+
+    Print the active Django settings.
+
+    Options:
+      -v VERBOSITY, --verbosity=VERBOSITY
+                            Verbosity level; 0=minimal output, 1=normal output,
+                            2=verbose output, 3=very verbose output
+      --settings=SETTINGS   The Python path to a settings module, e.g.
+                            "myproject.settings.main". If this isn't provided, the
+                            DJANGO_SETTINGS_MODULE environment variable will be
+                            used.
+      --pythonpath=PYTHONPATH
+                            A directory to add to the Python path, e.g.
+                            "/home/djangoprojects/myproject".
+      --traceback           Print traceback on exception
+      --format=FORMAT       Specifies output format.
+      --indent=INDENT       Specifies indent level for JSON and YAML
+      --version             show program's version number and exit
+      -h, --help            show this help message and exit
+

contrib/django_extensions/docs/runprofileserver.rst

@@ -0,0 +1,84 @@
+RunProfileServer
+================
+
+*First of all; we recommend that before you start profiling any language or
+framework you learn enough about it so that you feel comfortable with digging
+into it's internals.  Without sufficient knowledge it will not only be (very)
+hard but your likely to make wrong assumptions (and fixes). As a rule of thumb,
+clean well written code will help you a lot more then overzealous
+micro-optimizations will.*
+
+*This document is work in progress. If you feel you can help with
+better/clearer or additional information about profiling Django please leave a
+comment.*
+
+
+Introduction
+------------
+
+*runprofileserver* starts Django's runserver command with hotshot/profiling
+tools enabled. It will save .prof files containing the profiling information
+into the --prof-path directory. Note that for each request made one profile
+data file is saved.
+
+Per default the profile-data-files are saved in /tmp use the --prof-path option
+to specify your own target directory. Saving the data in a meaningful directory
+structure helps to keep your profile data organized and /tmp uncluttered. (Yes
+this is probably a bug on windows and other systems where /tmp does not exist)
+
+To define profile filenames use --prof-file option. Default format
+is "{path}.{duration:06d}ms.{time}" (Python
+`Format Specification <http://docs.python.org/3/library/string.html#formatspec>`_
+is used).
+
+Examples:
+
+  * "{time}-{path}-{duration}ms" - to order profile-data-files by request time
+  * "{duration:06d}ms.{path}.{time}" - to order by request duration
+
+gather_profile_stats.py
+-----------------------
+
+Django comes packed with a tool to aggregate these different prof files into
+one aggregated profile file. This tool is called *gather_profile_stats.py* and
+is located inside the *bin* directory of your Django distribution.
+
+
+KCacheGrind
+-----------
+
+Recent versions of *runprofileserver* have an option to save the profile data
+into a KCacheGrind compatible format. So you can use the excellent KCacheGrind
+tool for analyzing the profile data.
+
+Example::
+
+  $ mkdir /tmp/my-profile-data
+  $ ./manage.py runprofileserver --kcachegrind --prof-path=/tmp/my-profile-data
+  Validating models...
+  0 errors found
+
+  Django version 1.0-post-release-SVN-SVN-unknown, using settings 'complete_project.settings'
+  Development server is running at http://127.0.0.1:8000/
+  Quit the server with CONTROL-C.
+  [13/Nov/2008 06:29:38] "GET / HTTP/1.1" 200 41107
+  [13/Nov/2008 06:29:39] "GET /site_media/base.css?743 HTTP/1.1" 200 17227
+  [13/Nov/2008 06:29:39] "GET /site_media/logo.png HTTP/1.1" 200 3474
+  [13/Nov/2008 06:29:39] "GET /site_media/jquery.js HTTP/1.1" 200 31033
+  [13/Nov/2008 06:29:39] "GET /site_media/heading.png HTTP/1.1" 200 247
+  [13/Nov/2008 06:29:39] "GET /site_media/base.js HTTP/1.1" 200 751
+  <ctrl-c>
+  $ kcachegrind /tmp/my-profile-data/root.12574391.592.prof
+
+Here is a screenshot of how the above commands might look in KCacheGrind:
+
+  http://trbs.net/media/misc/django-runprofileserver-kcachegrind-full.jpg
+
+Links
+-----
+
+* http://code.djangoproject.com/wiki/ProfilingDjango
+* http://www.rkblog.rk.edu.pl/w/p/django-profiling-hotshot-and-kcachegrind/
+* http://code.djangoproject.com/browser/django/trunk/django/bin/profiling/gather_profile_stats.py
+* http://www.oluyede.org/blog/2007/03/07/profiling-django/
+* http://simonwillison.net/2008/May/22/debugging/

contrib/django_extensions/docs/runscript.rst

@@ -0,0 +1,65 @@
+RunScript
+=============
+
+:synopsis: Runs a script in the django context.
+
+
+Introduction
+------------
+
+The runscript command lets you run any arbritrary set of python commands within
+the django context. It offers the same usability and functionality as running a
+set of command in shell accessed by::
+
+  $ python manage.py shell
+
+
+Getting Started
+---------------
+
+To get started create a scripts directory in your project root, next to
+manage.py::
+
+  $ mkdir scripts
+  $ touch scripts/__init__.py
+
+Note: The *__init__.py* file is necessary so that the folder is picked up as a
+python package.
+
+Next, create a python file with the name of the script you want to run within
+the scripts directory::
+
+  $ touch scripts/delete_all_polls.py
+
+This file must implement a *run()* function. This is what gets called when you
+run the script. You can import any models or other parts of your django project
+to use in these scripts.
+
+For example::
+
+  # scripts/delete_all_polls.py
+
+  from Polls.models import Poll
+
+  def run():
+      # Get all polls
+      all_polls = Poll.objects.all()
+      # Delete polls
+      all_polls.delete()
+
+Note: You can put a script inside a *scripts* folder in any of your apps too.
+
+Using
+-----
+
+To run any script you use the command *runscript* with the name of the script
+that you want to run.
+
+For example::
+
+  $ python manage.py runscript delete_all_polls
+
+Note: The command first checks for scripts in your apps i.e. *app_name/scripts*
+folder and runs them before checking for and running scripts in the
+*project_root/scripts* folder. You can have multiple scripts with the same name
+and they will all be run sequentially.

contrib/django_extensions/docs/runserver_plus.rst

@@ -0,0 +1,125 @@
+RunServerPlus
+=============
+
+:synopsis: RunServerPlus-typical runserver with Werkzeug debugger baked in
+
+
+Introduction
+------------
+
+This item requires that you have the `Werkzeug WSGI utilities` (version 0.3)
+installed.  Included with Werkzeug is a kick ass debugger that renders nice
+debugging tracebacks and adds an AJAX based debugger (which allows to execute
+code in the context of the traceback’s frames).  Additionally it provides a
+nice access view to the source code.
+
+
+Getting Started
+---------------
+
+To get started we just use the *runserver_plus* command instead of the normal
+*runserver* command::
+
+  $ python manage.py runserver_plus
+
+  * Running on http://127.0.0.1:8000/
+  * Restarting with reloader...
+
+  Validating models...
+  0 errors found
+
+  Django version 0.97-newforms-admin-SVN-unknown, using settings 'screencasts.settings'
+  Development server is running at http://127.0.0.1:8000/
+  Using the Werkzeug debugger (http://werkzeug.pocoo.org/)
+  Quit the server with CONTROL-C.
+
+Note: all normal runserver options apply. In other words, if you need to change
+the port number or the host information, you can do so like you would normally.
+
+
+Using
+-----
+
+Whenever we hit an exception in our code, instead of the normal Django
+traceback page appearing, we see the Werkzeug traceback page instead.
+
+.. image:: https://f.cloud.github.com/assets/202559/1261027/2637f826-2c22-11e3-83c6-646acc87808b.png
+    :alt: werkzeug-traceback
+
+Along with the typical traceback information we have a couple of options. These
+options appear when you hover over a particular traceback line.  Notice that
+two buttons appear to the right:
+
+.. image:: https://f.cloud.github.com/assets/202559/1261035/558ad0ee-2c22-11e3-8ddd-6678d84d77e7.png
+    :alt: werkzeug-options
+
+The options are:
+
+
+View Source
+^^^^^^^^^^^
+
+This displays the source below the traceback:
+
+.. image:: https://f.cloud.github.com/assets/202559/1261036/583c8c42-2c22-11e3-9eb9-5c16b8732512.png
+    :alt: werkzeug-source
+
+Being able to view the source file is handy because you are able to get more
+context information around where the error occurred.  The actual traceback
+areas are highlighted so they are easy to spot.
+
+One awkward piece about this is that the page is not scrolled to the bottom.
+At first I thought nothing was happening because of this.
+
+
+Interactive Debugging Console
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When you click on this button a new pane will open up below the traceback line
+you're on. This is the money shot:
+
+.. image:: https://f.cloud.github.com/assets/202559/1261037/5d12eda6-2c22-11e3-802a-2639ff8813fa.png
+    :alt: werkzeug-debugger
+
+An ajax based console appears in the pane and you can begin debugging away.
+Notice in the screenshot above I did a `print environ` to see what was in the
+environment parameter coming into the function.
+
+*WARNING*: This should *never* be used in any kind of production environment.
+Not even for a quick check into a problem.  I cannot emphasize this enough. The
+interactive debugger allows you to evaluate python code right against the
+server.  You've been warned.
+
+.. _`Werkzeug WSGI utilities`: http://werkzeug.pocoo.org/
+
+
+SSL
+^^^
+
+runserver_plus also supports SSL, so that you can easily debug bugs which seem to popup when https is used. To use SSL simply provide a file name for certificates, a key and certificate file will be automatically generated::
+
+  $ python manage.py runserver_plus --cert cert
+  Validating models...
+  0 errors found
+
+  Django version 1.6.dev20130122125534, using settings 'mysite.settings'
+  Development server is running at http://127.0.0.1:8000/
+  Using the Werkzeug debugger (http://werkzeug.pocoo.org/)
+  Quit the server with CONTROL-C.
+   * Running on https://127.0.0.1:8000/
+   * Restarting with reloader
+  Validating models...
+  0 errors found
+
+  Django version 1.6.dev20130122125534, using settings 'mysite.settings'
+  Development server is running at http://127.0.0.1:8000/
+  Using the Werkzeug debugger (http://werkzeug.pocoo.org/)
+  Quit the server with CONTROL-C.
+  
+After you run above command, you can access your web application through https://127.0.0.1:8000. You will also find that two files are created in the current working directory, which are key file and a certificate file. If you run the above command again, these certificate files will be reused so that you do not have to keep accepting the self generated certificates from your browser every time. You can also provide absolute file for the certificate to be used if you already have one::
+
+  $ python manage.py runserver_plus --cert /tmp/cert 
+  
+Note that you need OpenSSL library to use SSL, and Werkzeug 0.9 or later if you would like to reuse existing certificates. To install OpenSSL::
+
+  $ pip install pyOpenSSL

contrib/django_extensions/docs/shell_plus.rst

@@ -0,0 +1,127 @@
+shell_plus
+==========
+
+:synopsis: Django shell with autoloading of the apps database models
+
+
+Interactive Python Shells
+-------------------------
+
+There is support for three different types of interactive python shells.
+
+IPython::
+
+  $ ./manage.py shell_plus --use-ipython
+
+
+BPython::
+
+  $ ./manage.py shell_plus --use-bpython
+
+
+Python::
+
+  $ ./manage.py shell_plus --use-plain
+
+
+The default resolution order is: bpython, ipython, python.
+
+You can also set the configuration option SHELL_PLUS to explicitly specify which version you want.
+
+::
+
+  # Always use IPython for shell_plus
+  SHELL_PLUS = "ipython"
+
+
+
+Configuration
+-------------
+
+Sometimes, models from your own apps and other peoples apps have colliding names,
+or you may want to completly skip loading an apps models. Here are some examples of how to do that.
+
+Note: This settings are just used inside shell_plus and will not affect your envirnoment.
+
+::
+
+  # Rename the automatic loaded module Messages in the app blog to blog_messages.
+  SHELL_PLUS_MODEL_ALIASES = {'blog': {'Messages': 'blog_messages'},}
+  }
+
+::
+
+  # Dont load the 'sites' app, and skip the model 'pictures' in the app 'blog'
+  SHELL_PLUS_DONT_LOAD = ['sites', 'blog.pictures']
+  }
+
+
+You can also combine model_aliases and dont_load.
+
+It is also possible to ignore autoloaded modules when using manage.py, like
+
+  $ ./manage.py shell_plus --dont-load app1 --dont-load app2.module1
+
+And, commandline parameters and settings in the configuration file is merged, so you can
+safely append modules to ignore from the commandline for one time usage.
+
+It is possible to use `IPython Notebook`_, an interactive Python shell which
+uses a web browser as its user interface, as an alternative shell::
+
+    $ ./manage.py shell_plus --notebook
+
+The Django settings module and database models are auto-loaded into the
+interactive shell's global namespace also for IPython Notebook.
+
+Auto-loading is done by a custom IPython extension which is activated by
+default by passing the
+``--ext django_extensions.management.notebook_extension``
+argument to the Notebook.  If you need to pass custom options to the IPython
+Notebook, you can override the default options in your Django settings using
+the ``IPYTHON_ARGUMENTS`` setting.  For example::
+
+    IPYTHON_ARGUMENTS = [
+        '--ext', 'django_extensions.management.notebook_extension',
+        '--ext', 'myproject.notebook_extension',
+        '--debug',
+    ]
+
+To activate auto-loading, remember to either include django-extensions' default
+notebook extension or copy the auto-loading code from it into your own
+extension.
+
+Note that the IPython Notebook feature doesn't currently honor the
+``--dont-load`` option.
+
+.. _`IPython Notebook`: http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html
+
+
+
+Additional Imports
+------------------
+
+In addition to importing the models you can also specify other items to import by default.
+These are specified in SHELL_PLUS_PRE_IMPORTS and SHELL_PLUS_POST_IMPORTS. The former is imported
+before any other imports (such as the default models import) and the latter is imported after any
+other imports. Both have similar syntax. So in you settings.py file:
+
+::
+
+    SHELL_PLUS_PRE_IMPORTS = (
+        ('module.submodule1', ('class1', 'function2')),
+        ('module.submodule2', 'function3'),
+        ('module.submodule3', '*'),
+        'module.submodule4'
+    )
+
+The above example would directly translate to the following python code which would be executed before
+the automatic imports:
+
+::
+
+    from module.submodule1 import class1, function2
+    from module.submodule2 import function3
+    from module.submodule3 import *
+    import module.submodule4
+
+These symbols will be available as soon as the shell starts.

contrib/django_extensions/docs/sqlcreate.rst

@@ -0,0 +1,45 @@
+sqlcreate
+==========
+
+:synopsis: Helps you setup your database(s) more easily
+
+
+Introduction
+-------------
+
+Stop creating databases by hand.  Your settings.py file already contains the correct
+information, so DRY.
+
+Usage
+-------------
+
+  $ python manage.py sqlcreate [--router=<routername>] | <my_database_shell_command>
+  
+It will spit out SQL which you can review (if you want) but ultimately you want to
+pipe it into the database shell command of your choice.
+
+If there was a good way to ensure that the user in the database settings had the
+proper permissions, we could submit the commands straight to the database.
+But due to the nature of this portion of the project setup, that will never happen.
+
+Example
+-------------
+
+PostgreSQL
+~~~~~~~~~~
+  $ ./manage.py sqlcreate [--router=<routername>] | psql -U <db_administrator> -W
+  
+
+MySQL
+~~~~~
+  $ ./manage.py sqlcreate [--router=<routername>] | mysql -u <db_administrator> -p
+  
+
+Known Issues
+------------
+
+ * CREATE DATABASE is not SQL standard so might not work everywhere.
+ * When using fallback user is not created and password is not set.
+   But it does try to do a GRANT to the database user.
+ * Missing options for tablespaces, etc.
+

contrib/django_extensions/docs/sqldiff.rst

@@ -0,0 +1,39 @@
+sqldiff
+=======
+
+:synopsis: Prints the ALTER TABLE statemens for the given appnames.
+
+Django command that scans all models for the given appnames and compares
+their database schema with the real database tables.
+
+It indicates how columns in the database are different from the SQL that would
+be generated by Django. This command is not a database migration tool. Though
+it might certainly be of help during migrations. It's purpose is to show the
+current differences as a way to checking or debugging your models compared to
+the real database tables and columns.
+
+Supported Databases
+-------------------
+
+Currently the following databases are supported:
+
+* PostgreSQL
+* Sqlite3
+* MySQL
+* Oracle
+
+Patches to support other databases are welcome ! :-)
+
+
+Example Usage
+-------------
+
+::
+
+  # View SQL differences for all installed application
+  $ ./manage.py sqldiff -a
+
+::
+
+  # View SQL differences for all installed application using text instead of SQL
+  $ ./manage.py sqldiff -a -t

contrib/django_extensions/docs/sync_s3.rst

@@ -0,0 +1,50 @@
+sync_s3
+=======
+
+:synopsis: sync your MEDIA_ROOT and STATIC_ROOT folders to S3
+
+Django command that scans all files in your settings.MEDIA_ROOT and
+settings.STATIC_ROOT folders, then uploads them to S3 with the same
+directory structure.
+
+This command can optionally do the following but it is off by default:
+
+  * gzip compress any CSS and Javascript files it finds and adds the
+    appropriate 'Content-Encoding' header.
+  * set a far future 'Expires' header for optimal caching.
+  * uploads only media or static files.
+
+
+Example Usage
+-------------
+
+::
+
+  # Upload files to S3 into the bucket 'mybucket'
+  $ ./manage.py sync_s3 mybucket
+
+::
+
+  # Upload files to S3 into the bucket 'mybucket' and enable gzipping CSS/JS files and setting of a far future expires header
+  $ ./manage.py sync_s3 mybucket --gzip --expires
+
+::
+
+  # Upload only media files to S3 into the bucket 'mybucket'
+  $ ./manage.py sync_s3 mybucket  --media-only  # or --static-only
+
+
+Required libraries and settings
+-------------------------------
+
+This management command requires the boto library and was tested with version
+1.4c:
+
+  http://code.google.com/p/boto/
+
+It also requires an account with Amazon Web Services (AWS) and the AWS S3 keys.
+The keys are added to your settings.py file, for example::
+
+  # settings.py
+  AWS_ACCESS_KEY_ID = ''
+  AWS_SECRET_ACCESS_KEY = ''

contrib/django_extensions/docs/validate_templates.rst

@@ -0,0 +1,35 @@
+validate_templates
+==================
+
+:synopsis: Checks templates on syntax or compile errors.
+
+Options
+-------
+
+verbosity
+~~~~~~~~~
+A higher verbosity level will print out all the files that are processed not just the onces that contain errors.
+
+break
+~~~~~
+Do not continue scanning other templates after the first failure.
+
+includes
+~~~~~~~~
+Use -i (can be used multiple times) to add directories to the TEMPLATE_DIRS.
+
+Settings
+--------
+
+VALIDATE_TEMPLATES_EXTRA_TEMPLATE_DIRS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can use `VALIDATE_TEMPLATES_EXTRA_TEMPLATE_DIRS` to include a number of template dirs per default directly from the settings file.
+This can be usefull for situations where TEMPLATE_DIRS is dynamically generated or switched in middleware or you have other template
+dirs for external applications like celery you want to check as well.
+
+Usage Example
+-------------
+
+ ./manage.py validate_templates
+