21–30 of 39 posts
http://jacobian.org/writing/django-apps-with-buildout/ Buildout. Like virtualenv but handles downloading correct required package versions too. gives you an isolated shell and django manager in your project directory. You can then distribute your project to different people and servers and ensure the correct version of python, django, etc. is used.
http://jacobian.org/writing/django-apps-with-buildout/ Buildout. Like virtualenv but handles downloading correct required package versions too. gives you an isolated shell and django manager in your project directory. You can then distribute your project to different people and servers and ensure the correct version of python, django, etc. is used.
FWIW, I don't believe Jacob recommends zc.buildout any longer. virtualenv + pip is easier and more Pythonic instead of Zope-like.
Anyway, Apache/mod_wsgi is perfectly fine and I wouldn't bother tweaking out that part unless you have an issue with it.
I'd strongly recommend using a cloud provider so you can test your deployment process. You can do it without a cloud provider, but you probably won't because it won't be trivially easy to create new servers.
http://www.djangy.com - in private beta, by wednesday we're hoping to invite several hundred more users. if you're in a time crunch, email me (dave@djangy.com) EDIT: email
Is this the project that was on HN a while ago asking who was interested? If I remember correctly people were giving the OP a hard time about using sqlite and not turning off debugging in a live environment. This project looks awesome and I'd really love an invite to the beta.
Earlier quoted context omitted.
Is this the project that was on HN a while ago asking who was interested? If I remember correctly people were giving the OP a hard time about using sqlite and not turning off debugging in a live environment. This project looks awesome and I'd really love an invite to the beta.
Yes it is the same project, I just looked it up. I was curious about this myself because I remembered being excited before the debug issue came up. Looking back at the thread, he owned up to it and assured that the actual project doesn't make such mistakes. The site does look a lot nicer than I recall, so I'm going to check it out. http://news.ycombinator.com/item?id=1616704
You really should use nginx to serve static files and route everything else to apache. The setup is dead simple.
Here's what I've found that helps tremendously: -Keep your software in a DVCS of some sort. I find Git and Mercurial to be great. -Use virtualenv to abstract away from your current environment's Python distribution. Start clean and download the packages you need. -Create a requirements file listing the packages that you need for you program. Put it in the same format that the 'pip freeze' command outputs, so that ins…
Have you tried keeping your settings in a package rather than in a module? Most introductions to django use settings.py to keep things simple (works out of the box using manage.py), however there is another (better) way!
You can store your settings in a package instead, so you have a settings directory, and inside this you have modules which represent a configuration. So you could have settings/development.py rather than settings.py, this just means you just change your django settings environmental variable to point to the correct configuration for each machine.
There are a few perks to managing settings this way, first you can extend existing settings (for example if you wanted to have some default settings that all configurations use, you could have a settings/shared.py and then do a `import * from .shared` in each of your configurations). Which means you have access to all the existing settings so you don't have to repeat yourself if you say want to add some middleware, or an application (think debug toolbar.)
And another benefit is that you are able to manage your settings through your version control system. Which I understand is not always ideal, however my guess is for most private projects this will be the best way of doing things! It also just seems to me like a much more pythonic way of organising your settings. (You can also do this for urls, however there's not as much benefit there, given that urls probably won't change from machine to machine that often.)
Here's what I've found that helps tremendously: -Keep your software in a DVCS of some sort. I find Git and Mercurial to be great. -Use virtualenv to abstract away from your current environment's Python distribution. Start clean and download the packages you need. -Create a requirements file listing the packages that you need for you program. Put it in the same format that the 'pip freeze' command outputs, so that ins…
These are some excellent points, the only things we do differently are: - We keep a local settings file for each environment, and those /are/ versioned. We have a /settings_local directory which contains each of the variants (localdev/dev/staging/df/live). The appropriate one is sym linked to /settings_local.py, which in turn is imported into settings.py. - We bypass Apache entirely and just plug Nginx FCGI into Djan…
I didn't read your comment (thoroughly) before posting my comment above, so I was parroting your point about organising project settings, however there are a few differences between our approaches. And I'd be interested to hear what you think about them. I don't work that actively with django at the moment, and never really had the opportunity to use my above system in a commercial project so maybe (probably) there are some gotchas I haven't thought about!
[1] virtualenv - http://virtualenv.openplans.org/
[2] virtualenvwrapper - http://www.doughellmann.com/projects/virtualenvwrapper/
[3] flint - http://igorpartola.com/projects/flint
[4] fabric - http://docs.fabfile.org/0.9.2/
I recommend nginx in front of gunicorn. This way nginx can sit up front and do what it does best: serve static media files and buffer requests and responses. Set up gunicorn under some kind of process manager. I use daemontools, but runit, upstart, monit, and others can work very well too. For updating code on the server, I'm a big fan of keeping it simple, and to me that means writing a small shell script that ssh's…