views:

42

answers:

2

I recently setup a deployment solution for my Django project using Fabric. The basic workflow being:

  1. Check out the latest source from git on the server.
  2. Copy it to a 'releases' directory and add a timestamp to the directory name.
  3. Update the 'current' symlink to point to the latest build.

This works just fine, only problem is, since the top level directory is a symlink called 'current' and that points to a folder like 'project_name_2010_10_04' ALL of the following Import statements will fail:

from project_name.app import models

...

INSTALLED_APPS = (
    'project_name.app'
)

...

urlpatterns = patterns('',
    (r'^$', 'project_name.app.views.index'),
)

So the solution I've found is to remove EVERY single reference to 'project_name' in my project, and the app seems to deploy and work just fine (for now). But this doesn't seem like the right way to solve the problem... mostly because in a newly created Django project the 'urls.py', 'settings.py' all reference the project name by default and also various Django documentation mentions using the project name for various things.

So to sum up my problem, is there a way to specify a package name that differs from the actual directory name?

+1  A: 

Simply put, you really shouldn't be using your project name hard-coded anywhere, especially in specific apps, as it just completely breaks their portability and re-usability.

Pewpewarrows
A: 

It seems that You have manage.py, urls.py and friends directly in the root of Your repository.

This is not right: on top-level, there should be setup.py, requirements.txt and project directory, inside which manage.py and friends should live.

(OK, if You want to be more compatible with non-Python world, it should live inside top-level src/ directory...)

Almad