Best Practices to Make your Apps Portable

[Sebastian Macias]

Today I had issues getting django registration to work in my django
project without having to modify every namespace inside django
registration. Basically what I ended up having to do is adding django
registration to my site-packages folder so I don't get errors like "No
module named registration.urls" and avoid having to change every
namespace in django registration to start with my project name This is
a pain for me as I'm making lots of changes to the django-registration
core. I also looked for help on IRC and was told that any third party
django apps are supposed to be added to the python path or put under
site-packages. This could end up being a tedious task as you would
have to remember what folders need to be copied to site-packages,
symlinked, etc when moving your project to a production server.
Wouldn't it be nice if you can just upload the project and all apps
(3rd party and your own) are inside of it?

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

[Collin Grady]

apps are portable if you don't make them in a project directory - as
for copying them to another server, nothing stops you from making a
"3rd_party" or some such folder in there that you add to pythonpath,
so that they don't have to be referenced by project.app

Or maybe make an "apps" directory that you add to pythonpath, then put
any and all apps in there.

[Adrian Holovaty]

On 7/24/07, Sebastian Macias <seba...@sebastianmacias.com> wrote:
> 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.

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 Kriesing]

That's a valuable info. To me it seemed some Django-standard and those
things are supposed to be well thought through, therefore we also
broke our heads over it a couple times ...
Thanks for the info.

Wolfram

--
cu

Wolfram

[Sebastian Macias]

Thanks a lot for the feedback everyone.

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:

[Ryan]

I like this setup. I will use this as a basis for my own upcoming
project.

Thanks.
RG

On Jul 25, 11:12 am, Sebastian Macias <sebast...@sebastianmacias.com>
wrote:

[Carl Karsten]

Can you post this to the wiki? or tell me to. one of us should. :)

Carl K

[Sebastian Macias]

I just added it to the wiki:

http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable

It's available in the resources page.

http://code.djangoproject.com/wiki/DjangoResources

Best,

Sebastian Macias

[JeffH]

I use the following:
my pythonpath includes /usr/local/lib/django/
within which I have:
apps/
app1/(models,views,urls)
app2/(models,views,urls), etc.
vhosts/
vhost1/(settings,urls)
vhost2/(settings,urls), etc.

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.)

[Toby Dylan Hocking]

> I just added it to the wiki:
>
> http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable

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.