DjangoStack
bitnami.org
bitnami.org
Really? What problems did you encountered?
sudo aptitude install apache2 libapache2-mod-wsgi \
mysql-server-5.0 python-mysqldb python-django
sudo aptitude install python-pip python-virtualenv
virtualenv ~/django-env
pip -E ~/django-env install Django
source ~/django-env/bin/activate
virtenvdir = '/path/to/virtual-env/lib/python2.5/site-packages/'
import sys
if virtenvdir not in sys.path:
sys.path.insert(0, virtenvdir)I've been using the one here: http://www.danceric.net/2009/03/26/django-virtualenv-and-mod...
virtualenv is a hack to work around the fact that python packaging is a joke.
That said, it seems to be useful.
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.
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
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)
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?
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.