views:

674

answers:

2

Hello Django experts

I am trying to create my first site in Django and as I'm looking for example apps out there to draw inspiration from, I constantly stumble upon a term called "reusable apps".

I understand the concept of an app that is reusable easy enough, but the means of reusing an app in Django are quite lost for me. Few questions that are bugging me in the whole business are:

What is the preferred way to re-use an existing Django app? Where do I put it and how do I reference it?

From what I understand, the recommendation is to put it on your "PYTHONPATH", but that breaks as soon as I need to deploy my app to a remote location that I have limited access to (e.g. on a hosting service).

So, if I develop my site on my local computer and intend to deploy it on an ISP where I only have ftp access, how do I re-use 3rd party Django apps so that if I deploy my site, the site keeps working (e.g. the only thing I can count on is that the service provider has Python 2.5 and Django 1.x installed)?

How do I organize my Django project so that I could easily deploy it along with all of the reusable apps I want to use?

+15  A: 

In general, the only thing required to use a reusable app is to make sure it's on the PYTHONPATH, so that you can import it from Python code. In most cases (if the author follows best practice), the reusable app tarball or bundle will contain a top-level directory with docs, a README, a setup.py, and then a subdirectory containing the actual app (see django-voting for an example; the app itself is in the "voting" subdirectory). This subdirectory is what needs to be placed in your Python path. Possible methods for doing that include:

  • installing the app into your site-packages directory using "setup.py install", if the app comes with a setup.py and you have root privileges
  • a symbolic link to the site-packages directory (also requires root privileges)
  • using software like virtualenv to create a "virtual Python environment" that has its own site-packages directory, and placing or symlinking the app there (highly recommended over all the "global installation" options, if you value your future sanity)
  • placing the application in some directory where you intend to place various apps, and then adding that directory to the PYTHONPATH environment variable

You'll know you've got it in the right place if you can fire up a Python interpreter and "import voting" (for example) without getting an ImportError.

On a server where you have FTP access only, your only option is really the last one, and they have to set it up for you. If they claim to support Django they must provide some place where you can upload packages and they will be available for importing in Python. Without knowing details of your webhost, it's impossible to say how they structure that for you.

Carl Meyer
Thanks, that was helpful. :)
Roland Tepp
A: 

An old question, but here's what I do:

If you're using a version control system (VCS), I suggest putting all of the reusable apps and libraries (including django) that your software needs in the VCS. If you don't want to put them directly under your project root, you can modify settings.py to add their location to sys.path.

After that deployment is as simple as cloning or checking out the VCS repository to wherever you want to use it.

This has two added benefits:

  • Version mismatches; your software always uses the version that you tested it with, and not the version that was available at the time of deployment.
  • If multiple people work on the project, nobody else has to deal with installing the dependencies.

When it's time to update a component's version, update it in your VCS and then propagate the update to your deployments via it.

stalemate
I kind of lean toward the virtualenv route.It is much cleaner approach and it is not too hard to have the virtualenv setup scripted so "committers" will also have it nicely set up (I am as lazy as anyone, so whenever I feel I want to restar, I prefer a nice tidy script that will re-create my environment to a bunch of manual steps...)
Roland Tepp