Another way is to use a settings wrapper such as django-harness[1], which: * helps organize apps (by name, without the notion of project) and eliminates the need to write absolute paths for templates, sqlite database and such stuff stored in the project directory; * simplifies version control of project code; * enables to extract applications to separate repositories without changing any import statements anywhere. The developer only needs to replace "settings" with "settings_wrapper" in default manage.py script.
By "project" I mean the directory with manage.py and settings.py while it may contain no apps. I think it's a good practice to only keep an application in that directory if it is a copy of some app which code is not publicly available or which is an experimental development related just to this project. Anyway it must never be imported as projectname.appname. [1] http://pypi.python.org/pypi/django-harness On Oct 6, 2:15 am, Kevin Teague <ke...@bud.ca> wrote: > On Oct 5, 6:45 am, Johan <djjord...@gmail.com> wrote: > > > Actually the TEMPLATE_DIRS does nothing. In order to get my apps to > > work outside of the project directory I edited the manage.py file and > > added : > > > import sys > > sys.path.append('..\\..\\..\\django-apps\\trunk') > > > This allows me to reference my applications from a central site > > (django-apps\\trunk) ... Is this the correct approach ? > > If scripts depend upon other Python projects you can either: > > - install project globally. which I do not recommended. > > - add project location to your PYTHONPATH. Lots of ways to manage > PATHs, but I like to do this by managing a 'profile.sh' file in the > root of your django site project. > > - manage sys.path explicitly from within your scripts. Which means > hard-coding in your scripts, so you can run into issues with multiple > devs/instances where paths vary. However, tools such as Buildout, can > automate script generation, so you check the project out of your VCS, > run the install tool, and the hard-coded bits are auto-generated for > your install. This gives you a robust deployment, since if you later > fiddle with your environment, you can still run your code. > > As for the creation of 'mysite.myapp' this pattern is introduced in > the Django tutorial. Pretty much every practice regarding installation > and project management in that tutorial is either outdated or geared > for making things as easy-as-possible. Unfortunately it really paints > you in corner and teaches a lot of bad habits. Once you want to move > beyond the simple use cases you need to take a big step back and re- > think and re-do how you're going to manage your django-based projects > and their dependencies. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
