How to re-use a reusable app in Django

Question

---

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?

Tal

Answer 1

In general, the only thing required to use a reusable app is to make sure it's on sys.path, 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:

• running pip install appname, if the app has been uploaded to PyPI (these days most are)
• installing the app with setup.py install (this has the same result as pip install appname, but requires that you first download and unpack the code yourself; pip will do that for you)
• manually symlinking the code directory to your Python site-packages directory
• using software like virtualenv to create a "virtual Python environment" that has its own site-packages directory, and then running setup.py install or pip install appname with that virtualenv active, or placing or symlinking the app in the virtualenv's site-packages (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.

Paladin

Answer 2

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.

Helmick

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