Categorized: Django
As pointed out by James Bennett in the comment below, this might not be the best idea.
Keep your Django Applications in a Subfolder
To keep your Django applications neatly filed into a subfolder (such as apps/), first add the following to your settings.py:
import os
PROJECT_ROOT = os.path.dirname(__file__)
Then in manage.py:
Right under #!/usr/bin/env python add:
import sys
from os.path import abspath, dirname, join
from site import addsitedir
Right before if __name__ == "__main__": add:
sys.path.insert(0, join(settings.PROJECT_ROOT, "apps"))
Now to figure out what to do in production…
Comments
A Django deployment which has to manually futz with
sys.pathfrom Python code just to find its own apps is a Django deployment that shouldn’t happen; typically it points to conceptual problems further up the chain (and the fact that you’ve copy/pasted bits from Brian’s code without seeing what you’re actually using is a further indicator of such).The Python path really isn’t that tough a thing to master, and once you know how it works, you just put application modules on the Python path. Not in an “apps” folder, not in the bizarre structure Pinax uses (and which I’ve complained about endlessly to the Pinax folks), just right there on your Python path where you know you can import them without any trouble.
For truly complex situations (and Pinax doesn’t even come close to complex enough to need this), use
virtualenvto create an isolated environment with its own separate import path you can drop things into.We put all of our apps in a folder called apps/ and have never had to do anything special besides referencing the new folder in import statements. What problem are you trying to solve?
The problem I’m trying to solve is just an aesthetic one for the organization of a project with multiple apps.
This is something that kind of bugs me about Django in general–there’s not an accepted default, so people just start doing it in different ways. I know apps are just Python modules and can live anywhere in your Python path, but it just seems messy to me to have apps in the same place as
templates/andsettings.pyand all the other things in the root of your project (at least if there are several apps in the project).I do appreciate being able to put them outside of the project entirely for reusable apps like django-tagging that will be used on more than one project.
I love having all my non-reusable apps right in the root of my project dir. I then do
instead of
in vim.
The mystery is why people didn’t create reusable apps in the first place, so instead of creating the hacks, how about making the non-reusable apps reusable and submit patches/fork them?
What about putting all symlinks to your django-apps in a directory like
This might be depending on the unix-distro that’s used. This directory was empty on my system. This way I don’t have to put the links in the primary system-wide $PYTHONPATH. And with a simple direcory listing I get all activated apps…
I’m using Debian Testing and found this while reading /etc/python2.5/site.py – printing sys.path showed the directory already.
@Tarak – That’s what I do when I’m installing 3rd party apps. I have something like
~/source/django_apps/where I keep them and symlink to mysite-packages.I think it’s a good solution, except that I would put that code inside the
settingsfile instead.I don’t understand the comment of James Bennett above. The python search path is designed to be changed, and that it precisely what django does. If django does it, why wouldn’t you?
What do you think about that?