My dilemma is... what is the point of having projects and apps if the
applications created for my project won't be portable in other
projects (becase the namespaces will always start with the project
name). I can't just copy and app from one project to another.
Basically what I see is that if I'm developing a web site (a django
project) and three apps that will be used on it (i.e. a blog, a poll
system, a rating system) and if I want to re use any of these apps in
the future in other projects or make them opensource I need to have a
django project for each app.
I'm still new to python and django (and loving them) and maybe these
are concerns that are easily addressed by methods I'm still not aware
of.
Any thoughts will be greatly appreciated.
Thanks,
Sebastian Macias
digital-telepathy inc
Or maybe make an "apps" directory that you add to pythonpath, then put
any and all apps in there.
Personally I never use "projects" -- they were just a quick thing we
made up just before we open-sourced Django, with the thinking being
"projects" would make it quicker and easier for people to get started.
They are *not* a good method to use if you want to distribute your
application, however.
We need better documentation about best practices to make apps portable.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Wolfram
--
cu
Wolfram
I have come up a perfect setup and folder structure (at least
perfect for my needs) that will allow me to work on generic apps and
project specific apps efficiently and just wanted to share it with
everyone in case it can save a anyone a headache.
*Folder structure for a django project*
/var/django_root/my_project_name/
urls.py
settings.py
apps/
my_project_specific_app_1/
my_project_specific_app_2/
my_project_specific_app_3/
*Folder structure for generic/portable apps*
/var/django_root/shared/
my_generic_portable_app_1/
my_generic_portable_app_2/
my_generic_portable_registration_app/
*Development Setup*
I added the following to the top of my_project_name/settings.py so it
appends the portable/generic apps folder to the python path.
DEVELOPMENT = True
if DEVELOPMENT:
import sys
sys.path.append('/var/django_root/shared')
For extended convenience I symlinked my portable/generic apps folder
to my django project so I can quickly make changes to my generic apps
without having to go outside my django project folder structure
ln -s `pwd`/var/django_root/shared /var/django_root/my_project_name/
shared
*Production Setup*
My Apache conf file:
<VirtualHost *>
ServerName championsound.local
ServerAlias *.championsound.local
SetHandler python-program
PythonPath "['/var/django_root', '/var/django_root/shared'] +
sys.path"
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE championsound.settings
PythonDebug On
</VirtualHost>
Note how '/var/django_root' and '/var/django_root/shared' are added to
the PythonPath
Enjoy it!
Sebastian Macias
On Jul 25, 6:19 am, "Adrian Holovaty" <holov...@gmail.com> wrote:
Thanks.
RG
On Jul 25, 11:12 am, Sebastian Macias <sebast...@sebastianmacias.com>
wrote:
Can you post this to the wiki? or tell me to. one of us should. :)
Carl K
http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable
It's available in the resources page.
http://code.djangoproject.com/wiki/DjangoResources
Best,
Sebastian Macias
within the config for each apache virtual host I have a different
DJANGO_SETTINGS_MODULE like vhosts.vhost1.settings
this way apps and vhosts are completely separate in the hierarchy, but
it is all within the same python path entry. It works well with
subversion because I have one code structure to capture all my apps
and vhosts and I can test out different vhost settings on different
servers by changing DJANGO_SETTINGS_MODULE in the apache config. I
have all my settings.py files import local_secrets.local_secrets, a
function that returns the proper database password and secret key
depending on whether a "DEVELOPMENT_MODE" parameter is set and on the
calling vhost. local_secrets.py is elsewhere on my pythonpath on each
physical server. That keeps that stuff out of my subversion tree.
templates and media are stored elsewhere where the designers have
access, using the same hierarchy as apps, but with an additional
vhosts directory containing overrides specific to particular vhosts.
In subversion I have code, templates and media directories below
trunk. Initially I had templates and media as subdirectories in each
app (to maximize app portability), but I found the access issues for
designers too cumbersome (chmod won't follow symlinks so granting
permissions to template and media subdirectories within each app is
unwieldy, and it was much easier to have media actually in the media
server docroot since we could use existing share permissions and have
user-restore capability (the docroots are mounted from a snapvaulted
SAN), and the designers don't play nice with subversion so I could
give them their own branch, etc.)
Looking there, I think you made a typo. The directory diagrams for
specific apps and generic apps are the same.
Furthermore, I can see how this system worked for you under the
constraints that your system/team imposed. However, I think that having
your apps (specific or general) simply live on the PythonPath is more
elegant, more DRY, and more in tune with what Django already does.
Remember when you set up Django and had to configure the PythonPath in the
apache http.conf file?
Consequently, I appreciate your idea as a contribution to the Django
developer community, but I think that recommending it as a "best practice"
is rather misleading.