4 ms·

Things I would suggest differently are to use a settings directory and have a settings/base.py then a settings/development.py settings/local.py settings/product

Things I would suggest differently are to use a settings directory and have a settings/base.py then a settings/development.py settings/local.py settings/production.py, and check all of these into git. Then put an environment variable export DJANGO_SETTINGS_MODULE=yourapp.settings.local into your postactivate script. There was a Django best practises book that has this stuff in it. Also use Fabric instead of make, and have a separate project (installable as a Python module) that has your "common" Fabric commands for deployment stuff. If you are on Linux, never ever ever do "sudo pip". Use your package manager for system packages.

oellegaard 14y ago
Actually I prefer to have only one settings file and configure everything else with environment variables. For me this is more clean. Make is generally installed on most systems, therfore I prefer it over fabric - but the idea is the same. I disagree about sudo pip on Linux, e.g. python-virtualenv wasn't updated for a long time in Ubuntu. Therefore, I still recommend getting the newest with pip. You coud apt-get python-pip, but most other things I would get from pip.
- edanm 14y ago
  "Actually I prefer to have only one settings file and configure everything else with environment variables. For me this is more clean." Heavily seconded. After many years of having separate files, this grew very unwieldy with multiple environments, machines, developers, etc. The env-variable route is much better, much easier to configure separately for different machines, etc. Also, this is the way Heroku does it - you load up a new server and run several "set env variable to {X}" commands to configure it. I think this is based on the 12-factor app system. (http://www.12factor.net/ http://www.12factor.net/)
reeses 14y ago
config layers are one of the best things ever. You can have settings/production.py set up without sensitive information for traceability and then the ops team can apply another config file with uids/passwords/red keys/etc.

oellegaard 14y ago

Actually I prefer to have only one settings file and configure everything else with environment variables. For me this is more clean. Make is generally installed on most systems, therfore I prefer it over fabric - but the idea is the same. I disagree about sudo pip on Linux, e.g. python-virtualenv wasn't updated for a long time in Ubuntu. Therefore, I still recommend getting the newest with pip. You coud apt-get python-pip, but most other things I would get from pip.

edanm 14y ago
"Actually I prefer to have only one settings file and configure everything else with environment variables. For me this is more clean." Heavily seconded. After many years of having separate files, this grew very unwieldy with multiple environments, machines, developers, etc. The env-variable route is much better, much easier to configure separately for different machines, etc. Also, this is the way Heroku does it - you load up a new server and run several "set env variable to {X}" commands to configure it. I think this is based on the 12-factor app system. (http://www.12factor.net/ http://www.12factor.net/)

reeses 14y ago

config layers are one of the best things ever. You can have settings/production.py set up without sensitive information for traceability and then the ops team can apply another config file with uids/passwords/red keys/etc.