

Show HN: Pre-configured Django project, Git repo, and virtualenv with 1 command - elimisteve
http://builtbyptm.com/blog/announcing-django-project-builder-v01/

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

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

~~~
mgrouchy
Django also allows you to specify project templates
[https://docs.djangoproject.com/en/dev/ref/django-
admin/#star...](https://docs.djangoproject.com/en/dev/ref/django-
admin/#startproject-projectname-destination) , very useful.

There is also support for app templates as well if you want to go that far.

------
zacharyvoase
I’m really sorry to get all critical, but if you personally have to SSH into
the server to do setup _or_ deployment—especially if you have to be
root—you’re doing it wrong.

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.

~~~
meric
Of course deploying as root is doing it wrong.

However, I still haven't found enough reason to switch from using SSH for
deployment. It's almost always three lines. ssh; git pull; ./manage.py
syncdb/migrate/collectstatic.

The only hindrance has been configuring the site to work on the server for the
first time, i.e what the site at this link claims to solve.

I've spent several hours on fabric before but gave up when I realised I've
spent more time on learning it than the time I spent deploying my code.

Can you tell me what I am missing out? I'm still relatively new to django
deployment and I feel I'm missing something but I haven't found it yet.

~~~
heretohelp
Idempotence, edge-cases, compliance ensurance.

What if you want to redeploy a configuration change to your web servers? What
if you want to ensure such changes get re-deployed everytime a change is made
to a config file?

~~~
meric
I guess if you are deploying the same site to more than 1 production server
these will become worthy problems to solve?

~~~
heretohelp
These are problems that can be solved in an afternoon, and then never repeated
ever again.

You _need_ to be using automation.

We have something like 16-17 servers, of which 4-5 are actually production
servers. Every single one of them was provisioned, configured, and are pushed
to via my code.

Everything from haproxy, to the frontend web servers, to the backend web
servers, to the frontend assets, the CDN, the image server, the backups, our
staging cluster, experimental cluster, databases...all of it is automated.

Do it once, do it right, do it in code, never do it manually again.

The idempotence is just so you can repeat the same job over and over if it
fails halfway between without causing any breakage.

------
leetrout
I wrote a tool (along similar ideas, starting out is always a needless time
sink) called GluStik (punning Paster)
[https://github.com/leetrout/glustik#default-djangoglu-
method...](https://github.com/leetrout/glustik#default-djangoglu-methods)

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?

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
<https://github.com/brack3t/django-modular-settings>

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")?

~~~
ajvb
We have included settings_local.py for development purposes, which gets
imported by settings.py if it can be found. The main purpose for this is for
the settings_local.py to be using sqlite3 rather than postgres, which is the
default in settings.py.

Another thing which is kind of hidden is the ptm1.4 branch. This is a branch
that includes a lot more, and will be growing quickly. We wanted the master
branch to be generic as possible, and have it so people can easily switch out
our defaults for their own, i.e. changing any of the files in django-files/
for their specific needs.

In regards to supporting other 'preferred practices', we welcome people to
fork this repo and contribute stuff back. The master branch will be staying
more generic, but we are all for best practices no matter if they are the
"Django way".

~~~
leetrout
You do see the difference between importing local settings into settings.py
and importing both of them from separate modules in a package's init so they
can override (per my example), yes?

I feel like you should take a harder look at the modular settings link I
included. MUCH better way to solve this problem.

------
Herbert2
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
<https://github.com/xenith/django-base-template>.

*Hardcoded ubuntu user and hardcoded py26 and py26 paths in different files: [https://github.com/prototypemagic/django-projectbuilder/blob...](https://github.com/prototypemagic/django-projectbuilder/blob/master/server-scripts/new-virtualhost.py) [https://github.com/prototypemagic/django-projectbuilder/blob...](https://github.com/prototypemagic/django-projectbuilder/blob/master/server-scripts/new-virtualhost-subdomain.py)

~~~
elimisteve
Release early, release often :-). We decided to launch this as soon as we
thought other people could benefit from it. That day is today.

As stated in the docs, the server-side auto-deploy code assumes you're running
Ubuntu. Removing such assumptions is a high priority (see TODO.md).

That said, the whole "start a new pre-configured Django project with lots of
stuff pre-configured" thing is ready now and only assumes you're on a Unixy
OS.

------
elimisteve
Direct link to GitHub repo: <https://github.com/prototypemagic/django-
projectbuilder/>

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

~~~
elimisteve
Congrats to your team for winning! Building a project in 54 hours is
awesome... Django Project Builder took a bit longer :-D

------
hsparikh
excited to give this a whirl this weekend.

------
mkramlich
shell scripting and templates for the win

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

~~~
RegEx
Have any Flask projects in the wild for us to see? The "Powered by Flask"
section in the Flask docs is full of quick toy projects.

~~~
heretohelp
<http://www.nutrivise.com/>

~~~
jiayo
The about link is giving me a 404.

~~~
heretohelp
Noice, I'll go fix that now. Thanks!

You get a free beta invite if you like for finding the bug.

~~~
anthonyb
Heh. Whatever nifty location rewriting javascript you're using makes it
impossible for me to browse your site - eg. <http://www.nutrivise.com/#terms/>
just points to your homepage.

Also: the 'terms of use' on that page are bogus. "The most advanced nutrition
system [evar!!1!]" vs. "NUTRIVISE MAKES NO WARRANTIES ABOUT THE ACCURACY,
RELIABILITY, COMPLETENESS, OR TIMELINESS OF THE MATERIAL OR THE WEB SITE ...
WHETHER BASED ON THIRD PARTY INFORMATION OR ON RATINGS GENERATED BY
NUTRIVISE." Oh? So what are people paying you for then, if not expert advice
that you're willing to stand behind?

~~~
heretohelp
The location rewriting is the Backbone router stuff that uses pushState.
Pretty common HTML5 stuff, you'd have to be using a moderately old web
browser. Most common one we're aware of that's guilty of not supporting this
is Firefox 3. What's yours in this case?

This is how terms of use work on most websites. In our case, we're in a
particularly tricky situation because the meal plans we lay out have the
ability to be incredibly useful to our users, but only if they actually comply
with them.

Since compliance isn't something we can ensure without a human being watching
them 24/7 (including when they're asleep in case they're sleep-eaters, an
actual phenomenon), we have to put in place that terms of use for that reason
and others.

Others including situations like people with severe allergies. We cannot
guarantee the absence of allergens in recipes/food coming from some of our
third party sources. To guarantee as much _would endanger the health of our
users and would be irresponsible_.

I'm sorry you don't feel we don't stand behind our product. We really do stand
behind what we do and believe we're working on something that has the
potential to help a large portion of westerners with weight issues.

The nutrition researchers and dietitians we work with feel so strongly about
our product that it's being used in a weight loss case study involving _many_
subjects that will allow us to further refine our already substantial
improvement on the current state of consumer nutrition.

My email is in my profile, contact me if you'd like to discuss this further.
I'd be interested to hear what you think we could do to better show we feel
confident about our software.

~~~
anthonyb
Yep, Firefox 3.6.24. The most up to date one on the version of Linux that I'm
using at work. I'm not sure why you/backbone need to rewrite the URL though -
surely a vanilla page would work just as well?

I understand compliance, allergies etc. are a tricky issue. There a more
narrow disclaimer and/or warning (eg. this recipe contains nuts/gluten/...)
would be definitely appropriate, not to mention useful if it were on the
actual recipe page.

But that's separate to the information that you're providing - I assume meal
plans and exercises? In that case the disclaimers completely overstep the
mark, and undermine any claims of competence. Would you trust an engineer who
disclaimed all liability should their bridge fall down? Or a doctor who wanted
you to waive the right to all negligence suits?

~~~
heretohelp
>Yep, Firefox 3.6.24. The most up to date one on the version of Linux that I'm
using at work. I'm not sure why you/backbone need to rewrite the URL though -
surely a vanilla page would work just as well?

It's not really that simple, it has to do with how Backbone falls back when
the pushState functionality is missing and how it interacts with the structure
of our site. We're currently looking into better ways to shim/workaround this
somewhat lackluster default functionality.

>I understand compliance, allergies etc. are a tricky issue. There a more
narrow disclaimer and/or warning (eg. this recipe contains nuts/gluten/...)
would be definitely appropriate, not to mention useful if it were on the
actual recipe page.

I just listen to the lawyers (and my CEO) on these matters. My job is to build
product to help people.

>In that case the disclaimers completely overstep the mark, and undermine any
claims of competence. Would you trust an engineer who disclaimed all liability
should their bridge fall down? Or a doctor who wanted you to waive the right
to all negligence suits?

Would you refuse to work with a doctor because he had malpractice insurance or
an engineer because he worked through an LLC? It would be irresponsible for
either of them to do without.

You seem to act as if our terms of use is somehow extraordinary when it is
anything but.

I'm not here to debate hypothetical circumstances, just make things to help
people.

Let me know if you want a beta invite via my email address so you can decide
for yourself.

~~~
lucian1900
One solution to the lack of pushState is to just offer the non-JS version of
your website to such old browsers. Easiest way to do that is to have the JS
bits disable themselves if pushState isn't found.

~~~
anthonyb
Or, you know, just use regular links. That part of the site isn't a web app,
it's just a regular web page. Why make things more complicated than they have
to be?

edit: Particularly when I just tried it at home in Chrome, and it ended up at
<http://www.nutrivise.com/terms/> anyway. Or did you come to the same
conclusion re: links?

~~~
lucian1900
My conclusion was essentially the same, yes. Degrade to links for browsers
without pushState.

