3 ms·

I feel the opposite, Over the 3 years or so I've worked with django full time there have been very good reasons to have different setups wrt environment, virtua

by 5h 15y ago

I feel the opposite, Over the 3 years or so I've worked with django full time there have been very good reasons to have different setups wrt environment, virtualenvs & web servers. That said I tend to use env vars to identify which environment an app is running in and build everything off that, which branch / db / logging target etc to use.

talaketu 15y ago
> use env vars to identify which environment an app is running in Be aware about issues between mod_wsgi and that approach - http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_Environment_Variables http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Appl...
- 5h 15y ago
  I'm aware of those, thankfully the things I set wont change within the life a single environment, a single variable to say dev/test/staging/production, could easily set in bashrc & wsgi script.
kennu 15y ago
Having an opinionated, best practice default doesn't have to prevent customization. I have always thought Rails is better than Django in this sense. There's one clear default way to do things, and then you can customize if you need to.
- talaketu 15y ago
  Not the best week to boast of rails opinionated best practice defaults in a django thread.
  - awj 15y ago
    Yeah, screwing up one thing obviously means that every single other idea they've had is boneheaded.
streeter 15y ago
Environment variables work extremely well when deploying on Heroku [1]. You can't exactly commit a local_settings.py file to your repo, so setting env variables is the only way to exclude sensitive keys and passwords from your source control. [1] http://rdegges.com/devops-django-part-3-the-heroku-way http://rdegges.com/devops-django-part-3-the-heroku-way