3 ms·

For those who would like to get started with Django, here's a skeleton project https://github.com/jordn/heroku-django-s3 https://github.com/jordn/heroku-djang

by jordn 13y ago

For those who would like to get started with Django, here's a skeleton project https://github.com/jordn/heroku-django-s3 https://github.com/jordn/heroku-django-s3 and guide helps get you set up quickly with: - hosting on heroku - static files on Amazon S3 - virtualenv(wrapper) isolated packages - environment and security critical variables removed from settings.py and stored as environment variables (following the 12-factor design ethic)

iends 13y ago
I have a couple of thoughts: 1. Why not use django-admin.py startproject --template=<url>? I typically do something like django-admin.py startproject --template=https://github.com/rdegges/django-skel/zipball/master https://github.com/rdegges/django-skel/zipball/master mynewproject so I don't actually have to clone 2. No runtime.txt for heroku? 3. Not specifying version numbers in your requirements.txt is very dangerous. I prefer something like "Django>=1.5.0,<=1.5.9"
- jordn 13y ago
  Thanks! Basically the answer is that I wasn't aware of the possibility of those things and have tried to keep it as simple as possible. I made a skeleton project for me as I couldn't find a decent guide for deploying django static's on s3. I fumbled my way through it and corrected and formalised it later so I could do it again. The https://github.com/rdegges/django-skel https://github.com/rdegges/django-skel project looks really useful as it contains everything and more you might want to use for a django project (and more), though not yet knowing what magic's it's doing I wouldn't yet jump to use. 1. That is very neat. I hope to try and copy that. 2. Noted. I didn't realise the need, as python 2.7.4 is the default. Can see it causing headaches if this were to change however. 3. Why is it dangerous? I preferred to keep the version numbers so it would always just install latest versions without any extra effort.
  - iends 13y ago
    The reason it's dangerous is that packages can introduce backwards incompatible changes. If you have a project that you don't work on for a few weeks/months and then need to fix a bug, you're going to have to spend additional cycles tracking down the issue and fixing either the backwards incompatible change, or adding a specific version to your requirements file anyway. I like to try and scope the package versions at the level the maintainer promises not to introduce breakages at.

by jordn 13y ago

iends 13y ago

I have a couple of thoughts: 1. Why not use django-admin.py startproject --template=<url>? I typically do something like django-admin.py startproject --template=https://github.com/rdegges/django-skel/zipball/master https://github.com/rdegges/django-skel/zipball/master mynewproject so I don't actually have to clone 2. No runtime.txt for heroku? 3. Not specifying version numbers in your requirements.txt is very dangerous. I prefer something like "Django>=1.5.0,<=1.5.9"

jordn 13y ago
Thanks! Basically the answer is that I wasn't aware of the possibility of those things and have tried to keep it as simple as possible. I made a skeleton project for me as I couldn't find a decent guide for deploying django static's on s3. I fumbled my way through it and corrected and formalised it later so I could do it again. The https://github.com/rdegges/django-skel https://github.com/rdegges/django-skel project looks really useful as it contains everything and more you might want to use for a django project (and more), though not yet knowing what magic's it's doing I wouldn't yet jump to use. 1. That is very neat. I hope to try and copy that. 2. Noted. I didn't realise the need, as python 2.7.4 is the default. Can see it causing headaches if this were to change however. 3. Why is it dangerous? I preferred to keep the version numbers so it would always just install latest versions without any extra effort.
- iends 13y ago
  The reason it's dangerous is that packages can introduce backwards incompatible changes. If you have a project that you don't work on for a few weeks/months and then need to fix a bug, you're going to have to spend additional cycles tracking down the issue and fixing either the backwards incompatible change, or adding a specific version to your requirements file anyway. I like to try and scope the package versions at the level the maintainer promises not to introduce breakages at.