It's easy to get carried away working and forget to ever commit your changes in Mercurial. But your version history will be a lot more useful later if you commit more often, every time you make a significant change to your project. Not too important for the tutorial, but more important when you start working on your own project.
The Django runserver automatically monitors your files and keeps up
with changes, EXCEPT if there are errors in an admin.py
file. For complicated and not-very-good reasons (i.e. it's a bug), if
there are errors in admin.py and you fix them, your admin
site will start working again, but the models registered in that
admin.py file will disappear from the admin. Just restart
your runserver and they'll show up again.
In part two of the tutorial, you set up your TEMPLATE_DIRS in settings.py. The quick and dirty way to do this is to hardcode a full absolute path:
TEMPLATE_DIRS = (
'/home/carljm/mysite/mysite/templates',
)
Obviously use your username, not carljm. And remember that a tuple with one element needs that trailing comma so Python knows it's a tuple, not just grouping parentheses.
The problem with the quick and dirty approach is that it breaks the first time you try to move your project; to another directory or another server. To fix this, we need to use some Python magic to dynamically figure out what directory our settings.py file is in. Here's the magic (put this at the top of your settings.py):
from os.path import dirname, join PROJECT_DIR = dirname(__file__)
The __file__ magic variable is always the full path to
the current file (in this case, settings.py). We just want the path to
the directory it lives in, so we use the dirname function
to strip off the final filename "settings.py" from that path.
Why did we also import the join function from the
os.path module? We need that to join two path-bits
together when we use PROJECT_DIR later on in settings.py:
TEMPLATE_DIRS = (
join(PROJECT_DIR, 'templates'),
)
This is equivalent to the TEMPLATE_DIRS we set above, except it
will keep working if you move your code to another location. (This
join function from os.path is different from
the join method on strings: instead of joining with some arbitrary
string, it always joins using the path separator of the current
operating system. We could manually concatenate strings with a '/',
but if we use os.path.join our code is also portable to
Windows, which uses '\' for the path separator. Also,
os.path.join is intelligent about handling leading or
trailing slashes on any of the path bits, so you don't end up with any
doubled slashes.)
Also in part two, you're asked to copy some template files from the Django source tree into your project. So where are Django's files? In your virtualenv:
$ cd mysite_env/lib/python2.6/site-packages/django/
There's the Django source tree: within that directory you can find contrib/admin/templates/... and copy things into the proper place in your project.
To get your project running on your own computer, we just need to install virtualenv and repeat the steps for setting up the virtualenv (but not the steps for creating your project directory, because that we'll just clone from dj via Mercurial).
These instructions will assume you're running on a Mac; if you're on Windows the process will be somewhat different. If any of you want to get your project running on Windows, let me know and I'll work you through it.
At a terminal shell, run "sudo easy_install virtualenv==dev". It'll ask for your password, and then give you more info than you want to know about the installation.
Now we just repeat the steps from in class, replacing the ones for setting up the project dir with a clone of your dj project:
$ virtualenv mysite_env $ source mysite_env/bin/activate $ easy_install pip==dev $ hg clone ssh://dj.goshen.edu/mysite/ $ cd mysite/ $ hg update $ pip install -r requirements.txt
Note that you'd need to add "username@" in front of "dj.goshen.edu"
if your local username on your computer is different from your
dj.goshen.edu username (which is your GC username). Also note that, as
usual, we had to do an hg update to actually get the
working tree populated with files after our hg clone.
At this point you should be ready to work on your project locally!
One other difference from working on dj is that your runserver command
can now just be python manage.py runserver (no need for a
specially unique port, nobody else is running Django's dev server on
your box), and the browser URL to see your work-in-progress is now
http://localhost:8000 (or
http://127.0.0.1:8000).