This stack is awesome. I spent months trying to build an easy-to-replicate django environment, and after I discovered bitnami, it was a piece of cake. Highly recommended for local development.

> I spent months trying to build an easy-to-replicate django environment

Really? What problems did you encountered?

  sudo aptitude install apache2 libapache2-mod-wsgi  \
    mysql-server-5.0 python-mysqldb python-django

Or if you want more flexibility in regards to available packages ...

  sudo aptitude install python-pip python-virtualenv
  virtualenv ~/django-env
  pip -E ~/django-env install Django
  source ~/django-env/bin/activate

And yeah, you still need to configure an app.wsgi and the site in /etc/apache2/sites-available, but it doesn't take longer than 20 minutes the first time, and then you can easily replicate it (personally I have a little script written by me that does the configuration). Just cargo-cult the stuff in here ... http://docs.djangoproject.com/en/dev/howto/deployment/modwsg...

Do you mind sharing your django.wsgi file? I'm trying to set this up right now for a site I'm working on. After looking throught the docs and some blog posts it wasn't clear to me how to hook up apache and virtualenv. Do you source in the env via the activate script? I feel like I'm missing something. Thanks.

Basically in the WSGI file (which is just python code) you need to insert the virtual-env site packages in sys.path, with something like this ...

  virtenvdir = '/path/to/virtual-env/lib/python2.5/site-packages/'

  import sys
  if virtenvdir not in sys.path:
      sys.path.insert(0, virtenvdir)

Hi,

I've been using the one here: http://www.danceric.net/2009/03/26/django-virtualenv-and-mod...

Sorry, pet peeve, but...

virtualenv is a hack to work around the fact that python packaging is a joke.

That said, it seems to be useful.

I view it as a tradeoff ... the ability to chdir to the package's directory and look directly at the source-code is priceless to me.

The alternative would be a GAC like .NET does, but then you need packages that are compiled in a single file with metadata attached. And you also need to attach to your app a configuration file that says which versions it uses.

And in Python the package's name can be relative to the directories loaded in sys.path, a very useful trait, and you also kind of lose that.

So Python's package system is more simple / brainless. And you can get by just fine with stuff like virtualenv.

> So Python's package system is more simple / brainless.

That's sort of my point. site-packages is basically a deep, dark pit that you can toss stuff in without trouble, but there is no obvious way to actually manage things once they're in there.

Basically I think Python really needs something like 'gem', and I feel like I'm the only one, which confuses me. shrug

> Basically I think Python really needs something like 'gem'

Huh? Does RubyGems manage versions?

In Ruby you have the same issues as with Python ... you still have a RUBYPATH and you still need to manually manage versions.

What 'gem' indeed does ... it can upgrade or delete installed gems ... and in Python the available utilities (easy_install and pip) don't.

But that's actually OK IMHO. In Python for pip-installed packages ... you just delete the package's directory or egg file. The conventions for Python's packages really help here.

And RubyGems is the nightmare of sys-admins. If you want a really good (maintainable / replicable) production setup, you need to use the standard package utilities of your OS ... e.g. aptitude and .deb packages for Debian/Ubuntu.

Otherwise you'll encounter conflicts between aptitude and /var/lib/gems all the f*ing time.

So no ... a good production setup is either using stuff like aptitude, which can manage external dependencies and can warn you against version conflicts ... or with a locally deployed site-packages (with stuff like virtualenv or sandbox for Ruby).

Rubygems is just a hack useful for the developer's localhost (the 'gem' utility, not the indexed repository of packages ... that's really useful, but Python has that with Pypi)

But that isn't my stack. What about nginx, memcache, and more recently a nosql tool like couchdb.

I got the impression the first is rocketing in popularity, the second is ubiquitous, and the third is inevitable at scale. Why start with anything less?

> But that isn't my stack. What about nginx, memcache, and more recently a nosql tool like couchdb.

If you're working with a project that needs nginx over apache, and needs nosql, then you won't be using a packaged solution anyway.

> Why start with anything less?

Because it's better than not starting.

Beisdes, "less" in this case is subjective.

Shameless plug: there's also http://www.turnkeylinux.org/django