Setting the Python path for the trunk version of Django

From bash (or other shell) you can manipulate the $PYTHONPATH to point to the parent directory, e.g.,
echo $PYTHONPATH
export PYTHONPATH="/newhome/django_x.x/trunk"

This will prepend the paths given to the existing python path list.

python.org :

For example, if PYTHONPATH is set to /www/python:/opt/py, the search path will begin with

['/www/python','/opt/py']

(Note that directories must exist in order to be added to sys.path; the site module removes paths that don’t exist.)

From within python, you can also change sys.path (import sys if you haven't) to point to your testing branch.

Example from python.org :

$ python
Python 2.2 (#11, Oct  3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
 '/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
 '/usr/local/lib/python2.3/site-packages']
>>>

To add a path, use something like :

sys.path.append('/workingdir/python/')

A Django-centric example from djangotricks (blog) :

import os, sys

SVN_PATH = os.path.abspath(os.path.join(os.path.dirname(__file__), "..", ".."))
DJANGO_PATH = os.path.join(SVN_PATH, "django_src", "trunk")
PROJECT_PATH = os.path.join(SVN_PATH, "myproject", "trunk")

sys.path += [DJANGO_PATH, PROJECT_PATH]

Additionally, unless you've suppressed the behavior, python loads site.py on execution, so you can also edit the site.py file, e.g. /usr/lib/python2.7/site.py :

The comments of the site.py file are also instructive.

$ more /usr/lib/python2.7/site.py

"""Append module search paths for third-party packages to sys.path.

****************************************************************
* This module is automatically imported during initialization. *
****************************************************************

In earlier versions of Python (up to 1.5a3), scripts or modules that
needed to use site-specific modules would place ``import site''
somewhere near the top of their code.  Because of the automatic
import, this is no longer necessary (but code that does it still
works).

This will append site-specific paths to the module search path.  On
Unix (including Mac OSX), it starts with sys.prefix and
sys.exec_prefix (if different) and appends
lib/python<version>/site-packages as well as lib/site-python.
On other platforms (such as Windows), it tries each of the
prefixes directly, as well as with lib/site-packages appended.  The
resulting directories, if they exist, are appended to sys.path, and
also inspected for path configuration files.

For Debian and derivatives, this sys.path is augmented with directories
for packages distributed within the distribution. Local addons go
into /usr/local/lib/python<version>/dist-packages,
Debian addons
install into /usr/{lib,share}/python<version>/dist-packages.
/usr/lib/python<version>/site-packages
is not used.

A path configuration file is a file whose name has the form
<package>.pth; its contents are additional directories (one per line)
to be added to sys.path.  Non-existing directories (or
non-directories) are never added to sys.path; no directory is added to
sys.path more than once.  Blank lines and lines beginning with
'#' are skipped. Lines starting with 'import' are executed.

For example, suppose sys.prefix and sys.exec_prefix are set to
/usr/local and there is a directory
/usr/local/lib/python2.5/site-packages
with three subdirectories, foo, bar and spam, and two path
configuration files, foo.pth and bar.pth.  Assume foo.pth contains the
following:

  # foo package configuration
  foo
  bar
  bletch

and bar.pth contains:

  # bar package configuration
  bar

Then the following directories are added to sys.path, in this order:

  /usr/local/lib/python2.5/site-packages/bar
  /usr/local/lib/python2.5/site-packages/foo

Note that bletch is omitted because it doesn't exist; bar precedes
foo
because bar.pth comes alphabetically before foo.pth; and
spam is
omitted because it is not mentioned in either path configuration
file.

After these path manipulations, an attempt is made to import a module
named sitecustomize, which can perform arbitrary additional
site-specific customizations.  If this import fails with an
ImportError exception, it is silently ignored.

References:
python.org docs, v2.7 search path
python.org docs, v3 search path
Djangotricks blog, a note on python paths
Martin Jansen : Django settings files for development and production

Good question. You can solved this issue with python. Open python interpreter and

Python 2.6
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
['', '/usr/lib/python24.zip', '/usr/lib/python2.4',
'/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk',
'/usr/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages',
'/usr/lib/python2.4/site-packages', '/usr/lib/site-python']

To change the path, just append/prepend entries to sys.path, which is a normal Python list, e.g.

>>> sys.path.append('/path/to/django/trunk')
>>> sys.path.insert(0, '/path/to/django/trunk')

Either one of those command should add it to your path.