Forums

Hi guys, I was curious what type of setups people do for getting debug mode on. I would really like to be able to have debug mode turned on locally, but off online at pythonanywhere server. I have thought of two options.

1. create a branch for my working code on my github, and another branch on the repo that is my live code with debug=false. This is my current approach.
2. Setting up a .gitignore to ignore my django settings.py file which I feel strongly is les desirable because I may have to change things there in the future.

Do people also have any other tips?

Also, how can I get rid of the help page for setting up a web app on the top of the site now that mine is up?

Thanks, Derek

[spam deleted by admin]

Hello, the above user should be suspended as for an off topic reply.

Sorry. I meant the spam message post. Thanks.

Yup, we've suspended the spammer's account. There seem to be a bunch of spambots posting here at the moment.

Re: your original post -- great question! There's lots of debate about the best way of doing that, but here are two ways we've used that I think work well:

• In your settings.py, have a line saying from local_settings import *, then add the local_settings.py to .gitignore. You can put the things that differ between dev and live in local_settings.py, and the common stuff can stay in the repo. So most of your stuff is version tracked, you only have (say) the database name and password and that kind of thing outside, with separate versions in your dev and live trees.
• Use environment variables. This is something we'll be supporting better in the future -- it's gaining popularity as a way of handling this kind of thing. But you can do it right now by using os.environ to get the environment variables in your settings.py and assign them to the appropriate settings variables, and you can set them in the WSGI file.

I think both of those options work better than having separate dev/live branches or than keeping all of your settings outside the repo.

Cool, I like both those options. By the way, if you guys decide to use a captcha to stop spam, please, please, please get an audio captcha or have an alternative way to post. I am a blind person, so a visual based captcha will lock me completely out of python anywhere (which is one of the reasons I was able to go with this solution).

Thanks for the warning, we'll make sure we do. BTW is ReCAPTCHA usable for you? It looks like they have an audio option, but it would be good to know if it works reasonably well.

I think it is because the site would allow the user to fall back to audio if the checkbox thingy fails. Google does this, and I think that is what recaptcha is. Another alternative would be to have me verify myself as a human when I sign up with an account, and then receive some sort of token that I use to prove with the captcha. For example, when the captcha comes up, there could be a link for I have a token, and I provide that token which is on some sort of white list. I don't know if anyone has taken that approach yet though.

As well, some of the captcha systems will disable audio captchas in their free versions, so that is one thing to be aware of.

Gosh, really? I understand that the providers want to make money, but charging for accessibility doesn't feel right to me. I'm sure there are other things they could use. Anyway, thanks for the heads-up -- we'll make sure we use something accessible.