Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command

I have been a Django developer for a few years now. If you are like me and you start a lot of new Django projects, trust me when I say you do not have time NOT to use this. Awesome tool that helps you get up and running with an new Django project quickly. Go, now, quick...start using it.

Or just have a skeleton/boilerplate code in a repo and clone it for each new project. Here's mine <a href="http://github.com/senko/dj-skeletor" rel="nofollow">http://github.com/senko/dj-skeletor</a> (feat. south, debug toolbar, raven/sentry, fabric).

I’m really sorry to get all critical, but if you personally have to SSH into the server to do setup <i>or</i> deployment—especially if you have to be root—you’re doing it wrong.<p>I also feel that if anyone or anything has to SSH into a server for deployment, it could be done better. I use Chef to automate all of this stuff; it's surprising that we have great tools like Chef, Puppet and CFEngine and people still feel the need to write custom collections of fragile scripts to get basic stuff done.

I wrote a tool (along similar ideas, starting out is always a needless time sink) called GluStik (punning Paster) <a href="https://github.com/leetrout/glustik#default-djangoglu-methods" rel="nofollow">https://github.com/leetrout/glustik#default-djangoglu-method...</a><p>Now GluStik scratched my itch of needing a very specific, custom layout, represented in code, and plopping in Django's files (like settings) so it provides hooks to use Django's templates. I'm curious what sort of design decisions went into project builder and what plans exist to support emerging trends?<p>For instance, I would much rather have a settings package with base.py and local.py inside where my local settings can extend base settings (like INSTALLED_APPS += ('debugtoolbar',) ala Brack3t's Modular Settings <a href="https://github.com/brack3t/django-modular-settings" rel="nofollow">https://github.com/brack3t/django-modular-settings</a><p>I realize this isn't the default Django behavior but I know more than a couple developers that use this format. So if project builder is about "sane defaults" and the masses prefer this is there a plan to support it (or other, similar developer centric preferences that are outside the "Django way")?

The quality of this leaves a lot to be desired* and you would be better off with using a 1.4 project from somewhere like <a href="https://github.com/xenith/django-base-template" rel="nofollow">https://github.com/xenith/django-base-template</a>.<p>*Hardcoded ubuntu user and hardcoded py26 and py26 paths in different files: <a href="https://github.com/prototypemagic/django-projectbuilder/blob/master/server-scripts/new-virtualhost.py" rel="nofollow">https://github.com/prototypemagic/django-projectbuilder/blob...</a> <a href="https://github.com/prototypemagic/django-projectbuilder/blob/master/server-scripts/new-virtualhost-subdomain.py" rel="nofollow">https://github.com/prototypemagic/django-projectbuilder/blob...</a>

Direct link to GitHub repo: <a href="https://github.com/prototypemagic/django-projectbuilder/" rel="nofollow">https://github.com/prototypemagic/django-projectbuilder/</a>

Awesome tool - we used it at Startup Weekend San Diego!

excited to give this a whirl this weekend.

shell scripting and templates for the win

You guys would lose your minds with envy if you saw how my company automates Flask :P