Changes between Initial Version and Version 1 of best-practices-to-work-with-3rd-party-applications-and-making-yours-portable

07/27/2007 12:03:18 PM (13 years ago)



  • best-practices-to-work-with-3rd-party-applications-and-making-yours-portable

    v1 v1  
     1= Best Practices to Work with 3rd Party Applications and Making yours Portable =
     3This is a guide to setting up your django projects and django apps  structure in an efficient way so you can work on portable/reusable applications and project specific applications simultaneously, use 3rd party apps, run them painlessly in the development server and happily deploying them to a production server  (apache/modpython at this moment only) without any namespace headaches.
     4Working with 3rd party / reusable applications used to be a pain for me as they are meant to live outside of your project folder structure, they either  needed to  live in your python site-packages folder or added to the python path; otherwise you would not be able to include them in your INSTALLED_APPS,  use them in your project at all and  you will end up seeing lots of “ImportError: No module named ...” type of errors.
     6Having to put 3rd party (and your own reusable apps) in your site-packages or having to add them to the python path was definitely not a way to go for me as I work for an agency and we are always developing and maintaining multiple applications so I would have to document which (out of all folders and files in  site-packages) are the 3rd party or reusable apps  used in each project, whether  they need to be symlinked somewhere, etc.. so other people on the development team can collaborate on the project and I don't forget how everything is supposed to be setup once we are ready to deploy the project to a production server.
     8So finally after getting feedback from the community and testing different approcaches I have come up with a project setup that works like a charm.
     10== Folder structure for a django project ==
     12   {{{
     16           apps/
     17             /my_project_specific_app_1/
     18             /my_project_specific_app_2/
     19             /my_project_specific_app_3/
     20   }}}
     23== Folder structure for 3rd partygeneric/portable apps ==
     25   {{{
     29           apps/
     30             /my_project_specific_app_1/
     31             /my_project_specific_app_2/
     32             /my_project_specific_app_3/
     33   }}}
     35== Development Setup ==
     37Added the following to the top  of my_project_name/ so it
     38appends the portable/generic apps folder to the python path run time while testing the app using the development server.
     41DEVELOPMENT = True
     42if DEVELOPMENT:
     43    import sys
     44    sys.path.append('/var/django_root/shared')
     47Note: don't forget to set DEVELOPMENT = False or remove those lines when deploying to a production server.
     49For extended convenience I symlinked my portable/generic apps folder
     50to my django project so I can quickly make changes to my generic apps
     51without having to go outside my django project folder structure
     54ln -s /var/django_root/shared /var/django_root/my_project_name/shared
     57== Production Setup ==
     58My Apache conf file:
     60<VirtualHost *>
     61  ServerName mydomain.tld
     62  ServerAlias *.mydomain.tld
     63  SetHandler python-program
     64  PythonPath "['/var/django_root', '/var/django_root/shared'] + sys.path"
     65  PythonHandler django.core.handlers.modpython
     66  SetEnv DJANGO_SETTINGS_MODULE my_project_name.settings
     67  PythonDebug On
     71Note how '/var/django_root' and '/var/django_root/shared' are both added the PythonPath
Back to Top