Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eighteen months of Django

dangoldin.com

Post reply on HN
Print view View original

81–85 of 85 posts

Re: Eighteen months of Django

#81

Post by jordn »

iends wrote: post #76
jordn wrote: post #70

For those who would like to get started with Django, here's a skeleton project 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)

I have a couple of thoughts: 1. Why not use django-admin.py startproject --template= ? I typically do something like django-admin.py startproject --template= 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"

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

Re: Eighteen months of Django

#82

Post by iends »

jordn wrote: post #81
iends wrote: post #76

Earlier quoted context omitted.

I have a couple of thoughts: 1. Why not use django-admin.py startproject --template= ? I typically do something like django-admin.py startproject --template= 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"

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 project looks really useful as it contains ever…

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.

Re: Eighteen months of Django

#83

Post by antihero »

scott_w wrote: post #67
antihero wrote: post #65

Earlier quoted context omitted.

Absolutely not. An added bit of compile time is the least of your worries and if you really don't want to compile stuff on production, look at packaging your virtualenv as a compiled deb/rpm. Never ever ever mix/depend upon system packages in your virtualenv. Ever.

You're always depending on system packages somewhere. Compiling isn't the only reason - sometimes it's necessary just to make the damn thing work. Some examples: * PIL - Using Pip's version on Ubuntu, you have to hack your directory structure and re-compile the whole thing or PIL doesn't compile in support for your image libraries. * psycopg2 - This is hit and miss (OS X comes to mind), but depending on the system ve…

PIL - Don't use PIL, use Pillow.

Psycopg2 - Well, it's just a client library - surely you will be making sure your client matches your server's version (whether that's local or a clust or whatever)? Sure your system will likely need Postgres headers installed, but why is that an issue? Actually, let me just check that. e: Yeah, you need libpq-dev installed, but I fail to see the point here? You need to make sure you have python-dev and a correct version of Python installed, too.

PyCrypto - Hmm, not had a problem with this hugely.

What I was suggesting doesn't involve a deb of individual packages, but a deb of the entire app/virtualenv.

Re: Eighteen months of Django

#84

Post by TomaszZielinski »

porker wrote: post #52

How well does Django handle complex forms? The kind where "if x = y show fields p-r (and make them required), if x = z jump the next screen)? I've just implemented one of these in PHP using the 'old' Symfony 1.4 and it was painful . I ended up hardcoding most of the frontend, and writing ridiculous modifications for "add another row" and validation. Is Django any better at that? Complex forms have been my pain point…

I would say that it's not much better out of the box but you can combine forms, formsets, custom validation, 3rd party helpers like django-cripsy-forms and support with something like KnockoutJS in the browser and voila :)

It would be great if there was a ready-made add-on combining all these areas but I don't know any personally. I also suspect think that writing such a generic helper might not be a great idea as everyone needs something a bit different, so using the mentioned lower level components and combining them on your own could be the best way to go here.

Re: Eighteen months of Django

#85

Post by TomaszZielinski »

porker wrote: post #62
scott_w wrote: post #56

Earlier quoted context omitted.

If I'm understanding you correctly, you want to have the fields on the form depend on the contents of what was entered on the previous form e.g. if user selects name, ask for name, otherwise ask for address. In that case, I tend to use class-based views and set different forms, templates etc. depending on those values. If the form is different enough, it's easier just to send them to a completely different URL.

Not quite - that happens sometimes and I use logic in the controller (ugh) to switch the form class. This is what I mean: an adaptive form http://screencast.com/t/SutggDU5 The server-side validation has to adapt depending on the data coming from the client-side, and varies a lot. Perhaps others don't build forms like this much and so web frameworks don't deal with them; I get one like this every few months!

Re server-side validation that adapts to the incoming data, I think it's easier to write a small mixin that fits your needs than to use a generic library (assuming there's one).
Post reply on HN