It'd be nice to be able to run fabric without using the --fabfile=src/myproject/fabfile.py switch every time.

It shouldn't intermingle with the code.

I've followed the project install instructions (i.e. create a new virtualenv, install requirements and the environment, copy example settings to local), but still getting the standard error:

Error: Could not import settings 'example.conf.local.settings' (Is it on sys.path? Does it have syntax errors?): No module named conf.settings

The problem seems to come from importing the common settings module - if you remove this and put all settings within that file then everything works.

I'm getting a recursive error with SmileyChris's fork when I try and run manage.py

When I look at the PROJ/PROJ/bin/manage.py itself it looks like this:

!/opt/webapps/PROJ/bin/python

EASY-INSTALL-DEV-SCRIPT: 'PROJ==0.1','manage.py'

requires = 'PROJ==0.1'
from pkg_resources import require; require('tms==0.1')
del require
file = '/opt/webapps/PROJ/src/PROJ/PROJ/bin/manage.py'
execfile(file)

So far the only way I've been able to get it to work is by replacing that with a stock manage.py.

But I'm also wondering if bin/manage.py should go away in lieu of django-admin.py since it's installed in a Virtualenv's bin folder by pip?

1. the case is wrong on the install cmd:
   pip install Sphinx (Sphinx should be capitalized)

If we really want to create a clean environment, we should be using virtualenv myproject --no-site-packages

This means that you have to build PIL for the env, which is a bit of a pain but it does mean you have a consistent environment.

The same goes for xapian as I found -- you could use your distro's default, but it means you're not locking down to a specific version of xapian.

Looking at readme, is python-setuptools really a direct requirement? Guess it is, but probably more likely this should be virtualenv as a requirement (which in turn, probably has setuptools as a depends)

Shouldn't it be included on the project template?

Suggested:
copyright = u'%d, Lincoln Loop' % datetime.date.today().year

manage.py doesn't take into account if DJANGO_SETTINGS_MODULE is in the environment already

I ran

django-startproject.py premium-support

and filled out the information as follows:

Project name [PROJECT]: premium-support
Project author [Lincoln Loop]: Michael
Development server [dev.lincolnloop.com]: [redacted]
Repository location [cambridge.lincolnloop.com]: [redacted]

After that, I ran

pip install -r requirements.pip

and then

pip install -e .

This went okay.

Finally, I ran

manage.py syncdb

and it bombed out with invalid syntax:

http://dpaste.de/tzy8Y/

Chris asked me to file an issue for this:

[9/29/11 4:30:05 PM] Chris: can't use dashes for your module name
[9/29/11 4:30:12 PM] Chris: it should probably protect against you trying to
[9/29/11 4:30:39 PM] Chris: add an issue in github for that

So....here it is.

I installed via:

pip install django-startproject

When running django-startproject.py myproj it fails silently w/o creating a project directory because the project_template directory isn't present within the installed package.

Based on the last commit, should it be moved? it's going to be ignored by the repo, so when trying to setup a local env an init.py will still need to be added manually.

I believe the statement:

TEMPLATE_CONTEXT_PROCESSORS += (
    'staticfiles.context_processors.static_url',
)

is obsolete as django (at least 1.3 does) automatically includes django.core.context_processors.static.

Seems like this would be better.

This is used in every project I know.

TEMPLATE_CONTEXT_PROCESSORS += (
    'django.core.context_processors.request',
)

How is the conf module used? What is conf.common? etc.

The static media is served from myproject/static/ and staticfiles can't find them until myproject is in the list of INSTALLED_APPS.

Why not just go the whole hog