4 ms·

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 --templat

by 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 iends 13y ago

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.