Ok, lots of stuff to put here. um... crap. ok, Django Config ============= Django Projects: ---------------- There are multiple ways of configuring Django to run under apache. We are running under fastcgi. You can have multiple Django projects running, each under its own fastcgi. A Django project proints to a single database where all the tables for all the apps in that project reside, along with the django admin and cache systems for that project. Two django projects cannot communicate with each other and should not point to the same database. There can be problems if PHP is pointing to the same database as Django, and this should be avoided (its really only a problem if they point to the same tables or both try to perform a rollback at the same time). This is due to the way django's configuration system works. You can only have one config active at a time, and the config determines the database and modules loaded in the project. Django requires that the project directory be on the python path, because the project is actually a python package. For this reason there is a single directory for all django packages which is on the python path. This protects the system from path style hacks (that is until python2.5 with '..' style include's which is a MAJOR security risk in general. Django Settings: ---------------- There are two settings files in the project. The 'settings.py' file at the top level is the production settings file for running on the server. The settings file 'devset.py' is the remote development settings file and has things like 'DEBUG' turned on as well as configs for dealing with a non-production environment (e.g. it uses cat instead of PHP). Django Apps: ------------ A django project can have multiple apps and this one does. Each app is hopefully independent of other apps in the project and is standalone. Forking: -------- Each year will be on a different SVN fork, and will consist of a different django project, one for each year. This means each year will have its own database, and the project directory will be renamed for each fork. All development will be done on the main trunk until that year goes live on the server, at which point it will be forked off to a branch and the trunk will be set to the next year. This will allow us to change even the version of django being used without effecting previous years which can still be modified on the branch and their data maintained in their databases with minimal impact and effort. Project Layout ============== Directory Structure: -------------------- django/ - django projects root (see above) pycon/ - project for a given year (see forking above) settings.py - server settings file devset.py - development settings file manage.py - django management and dev server script urls.py - root level url's parsing. each app should have an entry here. The import url method is perfered. views.py - root level default views for all apps and errors. tools/ - general tools (should be moved out of the project) core/ - core django extensions for the project. This is where context processors, custom template loaders and other django extensions global to the project are put. This is where the django PHP template extension and crumbs processing lives. templates/ - Core templates for the entire project. This is where the app template's back off to when looking for templates. apps/ - directory under which all apps live. / - The app in question templates/ / - We do this so that app sepecific templates and app template extensions work properly. All templates included in other templates or referenced in loaders should use the app name in the lookup path. This provides protection from collisions and allows for app extensions. The template loader system will search each of the app template directories in their install order, the app name protects from unseen collisions, and allows for app2 to extend app1. Some more should be added on extended models, views and urls. There are bugs with model and view packages in the app package which are fixed in the django 'magic-removal' branch. Once this is in the django mainline, and we have rewritten everything to work with that new style of django code, we should add this convention and adhere to it. SVN Structure: -------------- This is a little different from normal projects in that the branches are the live systems, and the trunk is the active development system. django/ trunk/ pycon/ - current development system, not-live. year is continually updated (see forking above) (should this directory be removed?) tags/ pycon--init - tag for the initial system? pycon--live - tag for the system used durring convention pycon--end - tag for the system before archival/removal branches/ pycon - forked year, server points to theses branches Conventions =========== ok, bad pun. Etched in stone: indentation is 4 Spaces, no tabs. 80 char limit on python code lines and everywhere else if possible. Line breaks after ',' NOT before. Limit use of lambda. No map or filter use allowed. Death to reduce. No I am not kidding. No I don't care what you think. Editors have nothing to do with it. Don't like it? Don't work on this code. Installing ========== We are currently running with the following versions of software: Django-0.91 (with 1281_patch2.diff patch) postgresql-8.1.2-1 win-psycopg24 (or linux equiv) egenix-mx-base-2.0.6.win32-py2.4.exe (or linux equiv) Development =========== For external development of apps you will need to do the following: get a checkout from SVN: svn co http://us.pycon.org/repo/django/trunk/pycon C:/django/ Set your PYTHONPATH appropriatly: PYTHONPATH=C:/django Set your Django setting module to the development settings file. DJANGO_SETTINGS_MODULE=pycon.devset This settings file assumes you have: progresql installed locally. with the user 'progres' and the DB 'pycon2006' with the password 'pycon2006' Initialize the Django system (do only once): python pycon/manage.py --settings=pycon.devset init python pycon/manage.py --settings=pycon.devset createsuperuser Install the applications (do only once): python pycon/manage.py --settings=pycon.devset install admin python pycon/manage.py --settings=pycon.devset install survey python pycon/manage.py --settings=pycon.devset install mappy python pycon/manage.py --settings=pycon.devset install maps python pycon/manage.py --settings=pycon.devset install roomy Start the local dev http server: python pycon/manage.py --settings=pycon.devset runserver Normally the dev server will auto-reload if a file has been modified. Every so often a change will cause the dev server to crash or stall which will require a break and restart. This type of error whould also crash the fast cgi process. Chenges should be committed to SVN, then on the server the fastcgi should be stopped, the server view updated, and the fastcgi restarted. No development should be done on the server itself. (HA!) We should be able to construct some standard tests and a test framework. We should also have a development DB export which is maintained (maybe one export per app and one for the main admin), for such a framework, checked into svn. Because django views accept a request object and return a django rendered object we can do testing of the apps without a webserver or the dev server running. Baseline/diff with filtering would work best for this style of testing. Whitespace would be optionally ignored (some files like iCal use whitespace in evil ways while html ignores it). Other patterns would also need to be filtered.