There is also support for app templates as well if you want to go that far.
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.
Did you look at the actual main aspect of this simple tool, or just the one folder with the server-script? As previously mentioned. The main aspect of this is the automatic _Django Project Builder_, not "a collection of fragile scripts to get basic stuff done".
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.
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?
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")?
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".
I feel like you should take a harder look at the modular settings link I included. MUCH better way to solve this problem.
*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...
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.
The core aspect of this is the Django defaults and the front-end stuff. The server scripts are in a separate folder for a reason.
I will say this though, I've been using Fabric for a very long time and abuse it with glee.
Are there any dev-opsy/provisioning/whatever type pain points you'd like a blog post or exposition on?
Edit: I'm the CTO. I'm open to open sourcing our stuff, but the lack of generalizability makes it less than useful. There's an abundance of magic in our stack that automates everything. Idempotence was a core design goal.
Edit2: For local development, I automate everything surrounding the python packages and the virtualenvs for the various repos we have as well. It's pretty damned handy.
