Hacker News new | past | comments | ask | show | jobs | submit login

It's annoying how there is no canonical way to do it. You need to spend some mental energy learning how to do this when starting up a Django project. Django should really integrate one solution into the django core, and then everyone can just use that. Make it much easier.



I like Django quite a bit, but it boggles the mind how many developer hours have been spent solving the same basic setup problem over and over again.


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.


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.


Not the best week to boast of rails opinionated best practice defaults in a django thread.


Yeah, screwing up one thing obviously means that every single other idea they've had is boneheaded.


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


> 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#Appl...


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.


Am I the only person that uses pure and simple symlinks? https://en.wikipedia.org/wiki/Symbolic_link


"Am I the only person ..."

The answer to this is always no.


The problem with symlinks is that there's manual intevention needed when you deploy.


Not at all. Store settings_dev.py and settings_prod.py in your repository. What will be different on production machine and on local one is the symlink file called settings.py.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: